# Premium Page Redesign > Use this skill whenever the user wants to redesign, level-up, modernize, or premium-ify a website landing page or similar marketing-style page — hero landing, marketing landing, sales page, pricing-as-landing, about/team landing, portfolio landing, agency landing, product launch landing, coming-soon, or single-page site. Triggers on phrases like "redesign this landing page", "make this landing premium", "make this look $20K", "modern beautiful landing", "1-shot landing redesign", "premium hero", "level up this landing", "redesign my homepage", "make this not look AI-generated", "high-end landing UI", "luxury landing feel", "world-class landing design", or any request to rebuild a marketing-facing page's visual design. Use this skill even if the user only shows a screenshot, URL, or HTML snippet of a landing/marketing page without explicitly asking for "premium". Do NOT use for app dashboards, login/signup flows, blog post bodies, blog indexes, or product-detail e-commerce pages (those are app/utility pages, n - Skill: `maybackcompany/premium-page-redesign` (Agent Skill, multi-file: 11 files) - Install (CLI): `npx skillmds@latest add maybackcompany/premium-page-redesign` - Raw SKILL.md: https://api.skillmd.com/api/skills/maybackcompany/premium-page-redesign/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: MaybackCompany (https://skillmd.com/u/maybackcompany) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/maybackcompany/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: | File | When to read | |---|---| | [references/typography.md](references/typography.md) | Always. Font tier list + clipping rules + scale. | | [references/color.md](references/color.md) | Always. Palette rules + OKLCH tokens + accent placement. | | [references/layout-grids.md](references/layout-grids.md) | Always. Bento tessellation + section flow + spacing scale. | | [references/sections.md](references/sections.md) | When building section-by-section. Library of premium section patterns (hero, features, pricing, FAQ, testimonials, person-card, footer). | | [references/visual-details.md](references/visual-details.md) | Always. Header, logo, buttons, icons, motion, shadows, borders. The "smell" rules. | | [references/copy.md](references/copy.md) | When writing or rewriting copy. Voice + headline rules + the em-dash/emoji ban. | | [references/never-do.md](references/never-do.md) | Always. Zero-tolerance failure list. Skim before shipping. | | [references/checklist.md](references/checklist.md) | At the end, before declaring done. | | [references/intake.md](references/intake.md) | Always, before any code. The 15-question intake gate. | ## Intake gate (required before any code) Before drafting layout, copy, or components, run [references/intake.md](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: | Landing variant | Tells | Layout posture | |---|---|---| | SaaS / product marketing landing | hero + features + logo bar + testimonials + pricing teaser + CTA | Vertical narrative. Big hero. Bento mid-page. Multiple proof points. | | Pricing-as-landing | 2-4 tier cards as the primary content + FAQ + footer | Comparison-focused. One highlighted tier. Minimal pre-pricing narrative. | | Portfolio landing (designer / dev / creative) | intro + selected work + philosophy + contact CTA | Editorial. Restrained. Work-as-hero. Person-card present. | | Agency / studio landing | manifesto-style hero + case studies + clients + contact | Brand-bold or editorial. Case studies do the work. | | Personal / about landing | photo + bio + projects + contact | Editorial. Single column or 2-column. Photo + role required. | | Product launch / coming-soon | one hero + email capture + 1-2 supporting details | Minimal. Single screen ideal. One CTA. | | Sales / single-product landing | hero + problem + solution + proof + offer + FAQ + CTA | Long-scroll narrative. Repeated CTA placements. One offer. | | Event / conference landing | hero + speakers + agenda + tickets + venue | Mixed-media. Person-cards for speakers. Date + place prominent. | | App / tool homepage (mobile or desktop) | hero + features + screenshots + download CTAs | Image-led. Store badges. Device frames done tastefully or not at all. | 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.