Premium Page Redesign

Premium Page Redesign

Goal: produce one-shot, production-grade page redesigns that pass the "$20K screenshot bar" — a senior designer would screenshot this and be proud. No AI-generated tells. No template feel. No mid-tier slop.

When this fires

Any request to redesign, rebuild, refresh, modernize, or premium-ify a full page. URL, screenshot, HTML snippet, or even a vague "make this better" — if it's a page-scale visual rebuild, run this skill.

Step 0 — Read before you build

Before drafting anything, load context. Each reference file has a specific job — read the ones relevant to the page type, not all of them blindly:

Intake gate (required before any code)

Before drafting layout, copy, or components, run references/intake.md — the 15-question intake gate covering brand, audience, offer, posture, content inventory, integrations, and constraints.

Two paths:

1. User answers the intake — proceed with their answers as the source of truth.

2. User says "decide for me", "no questions", or otherwise opts out — make defensible assumptions and state them explicitly in a 3-line block before generating any code:

   Assumptions (no intake answered):
   - Posture: Editorial premium · Accent: oklch(0.66 0.18 75) warm amber · Sans: Inter · Display: Geist
   - Audience: founder/operator · Offer: SaaS marketing landing · CTA: "Start a 14-day trial"
   - Integrations: none assumed — no Stripe/Cal/Whop/Discord wiring unless mentioned
   

   The user can correct any line before you continue. If they say nothing, those assumptions are binding for the rest of the build.

Never skip the intake gate. A page built on guesses fails the premium bar because it has no point of view.

Preserve list (patch mode — editing existing site)

When the user asks you to redesign an existing page (not greenfield), you are operating in patch mode. The visual layer is yours to rebuild. Everything below stays untouched unless the user explicitly tells you to change it:

• Pricing logic — price values, billing intervals, currency
• Currency/billing toggles — monthly/yearly switches, USD/EUR/GBP switches
• Checkout — Stripe payment links, Whop checkout URLs, Lemon Squeezy buttons, any cart/checkout route
• Auth flows — sign-in, sign-up, password reset, magic links, OAuth providers
• FAQ accordion behavior — open/close state machines, single-open-at-a-time rules
• Modals and menus — open/close logic, focus trap, escape-to-close, scrim handling
• Embeds — Cal.com booking, Discord widget, Typeform, Calendly, YouTube, Loom
• Analytics events — PostHog/Segment/GA4 event names and payloads
• Routes — URL paths, slugs, redirects, dynamic segments
• SEO metadata — canonical URLs, robots directives, structured data IDs (you may rewrite title/description copy, but preserve the schema shape)

Rule of thumb: if it has business logic, integrations, or analytics attached, preserve it and rebuild only the visual shell around it. When in doubt, ask before deleting.

Step 1 — Infer the page autonomously

User rarely tells you the page type. Figure it out:

1. If URL given: fetch with WebFetch or have the user paste rendered HTML. Read the actual content.
2. If screenshot: read it. Identify hero, sections, CTAs, footer, navigation.
3. If HTML/code given: read the file. Note the route, the imports (shadcn? Magic UI? plain HTML?), the existing components.

Then classify which landing variant you're building. Every variant shares the same DNA — hero, narrative sections, social proof, CTA, footer — but the rhythm shifts:

If the page genuinely doesn't fit a landing variant — it's an app dashboard, login flow, blog index, blog post body, or e-commerce product-detail page — stop and tell the user this skill is wrong for the job rather than forcing landing patterns onto an app/utility page.

If the variant is unclear after inspection, ask the user — but only one question, and only if you genuinely can't tell.

Step 2 — Decide the design posture

Pick one posture and commit:

• Editorial premium (Stripe, Linear, Vercel docs) — restrained palette, big type, generous whitespace, no decoration
• Atmospheric premium (Apple, Arc, Raycast) — soft gradients, layered depth, glass-but-tasteful, hero imagery
• Utility premium (Notion, Figma, Superhuman) — dense but breathable, function-first, tiny ornament
• Brand-bold (Loops, Resend, Cal.com) — one signature color, oversized type, lots of confidence

Don't mix postures within one page. Don't Frankenstein.

Step 3 — Run the 11-step build

Execute in order. Don't skip.

1. Inventory — list every section the page needs in vertical order
2. Wireframe in your head — what's above the fold, what's the rhythm, where does the eye rest
3. Choose fonts — pick from references/typography.md tier list. Display + body. Max 2 families.
4. Choose palette — 2-3 neutrals + 1 accent (references/color.md). OKLCH tokens. No default Tailwind palette.
5. Set the scale — type scale, spacing scale, radius, max-width container. Lock once.
6. Build the hero — see references/sections.md hero patterns. Headline ≤ 3 lines. No clipping.
7. Build mid-page — alternate rhythm: full-bleed → bento → split → testimonial → bento → CTA. Avoid same-shape repeats.
8. Build the footer — see references/sections.md footer. Real links. Real legal. Not a placeholder.
9. Apply visual details — references/visual-details.md. Icons replace numbers. No sticky header by default. Logo top-left, small.
10. Pass the never-do filter — references/never-do.md. If anything trips, fix before continuing.
11. Pre-launch checklist — references/checklist.md. Every item.

Step 4 — Verify before declaring done

This is where AI-generated work gets caught. Don't skip.

• Build it (Next.js: pnpm dev; static: open in browser; Storybook: render story)
• Screenshot at 1440px and 375px — the page must hold at both widths
• Read the page out loud — does the copy embarrass you? Rewrite.
• Look at every section in isolation — does each one earn its place? Cut the weakest.
• Zoom out to 50% — does the rhythm work? Are sections the same height? (They shouldn't be.)
• Final never-do pass — re-read references/never-do.md. Be honest.

Acceptance criteria

Page is done when:

Required files (Next.js App Router skeleton):

• app/page.tsx present and renders the page server-side
• app/layout.tsx present with metadata export (title, description, OG, Twitter)
• app/globals.css defines the OKLCH token set (--background, --foreground, --subtle, --accent, --accent-hover, --border)
• tailwind.config.ts references those tokens — no default Tailwind palette (bg-blue-500, text-purple-600) anywhere in the page

Metadata strings (zero tolerance):

• metadata.title — no em dash (—, –, —, –), no emoji
• metadata.description — no em dash, no emoji, no AI-tell verbs ("Unlock", "Supercharge", "Revolutionize")
• openGraph.title / openGraph.description — same rules
• twitter.title / twitter.description — same rules

Color (hard ceiling):

• Exactly one chromatic OKLCH hue across --accent / --accent-hover / --accent-subtle
• Neutral grays derived from that same hue or from a neutral 250–270 family
• Two chromatic families = auto-fail (run the grep in references/never-do.md before shipping)

Primary CTA (verb + noun, banned list enforced):

• Format: verb + noun (e.g. "Start a 14-day trial", "Book a strategy call", "Join the community", "Apply for membership", "Compare plans")
• Banned literal strings: "Get started", "Learn more", "Click here", "Submit", "Sign up" (alone — needs context like "Sign up for the beta")

Section rhythm:

• Adjacent sections alternate bg-background / bg-subtle (or bg-background / full-bleed image / bg-background)
• Never two adjacent sections with the same background — kills vertical rhythm

Original premium bar (still enforced):

• Senior designer would screenshot it without shame
• No AI-generated tells (em dashes in copy, emoji in headlines, purple gradients, sticky-header-by-default, numbered section markers, centered-everything, blur abuse, drop-shadow soup, transition-all)
• Headlines never clip. Letters complete top-and-bottom, descenders breathe
• ≤ 3 lines for any hero/section headline
• Bento sections tessellate (no fixed grid repetition, no same-height row across)
• Person-cards always have real photo + name + role + (optional) one-line bio. Never initials/monogram. Never a name alone.
• Testimonials always have real photo + name + role + specific outcome quote. No initials, no vague praise, no fabrication.
• Icons replace numbered section markers (no "01.", "02." labels)
• Header is not sticky unless the page demands it (long-scroll app, docs)
• Logo top-left, sized small (not centered, not huge)
• Buttons follow references/visual-details.md — no full-width unless on mobile, no rainbow CTAs, all 8 states defined (primary/secondary/ghost/disabled/loading/hover/active/focus-visible)
• Copy: no em dashes, no emojis in headlines, no "Unlock", "Supercharge", "Revolutionize", no "Built different"
• All animations: transform/opacity only, ≤ 200ms, no transition-all
• Responsive: page holds at 390px, 768px, and 1440px without horizontal overflow (see references/checklist.md matrix)

If any item fails, fix before shipping. No exceptions.

What this skill is NOT

• Not a component library — uses shadcn/ui + Magic UI + Lucide, doesn't reinvent
• Not a copy generator — guides voice but the user owns the actual words
• Not a brand designer — assumes brand identity exists or uses sensible defaults
• Not for partial edits — for single-component tweaks, just edit directly

Stack assumptions

• Next.js + TypeScript strict
• Tailwind with OKLCH color tokens (not default palette)
• shadcn/ui base components
• Magic UI for premium effects (sparingly)
• Lucide icons
• pnpm

If the user's stack differs, adapt — the principles transfer.