Type-Led Launch Design

Overview

Use this skill when a frontend task needs a serious, minimal launch page that does not look like a generic generated template. The canonical design standard is references/DESIGN.md; read it before creating or reviewing any page.

The job is narrow: produce a type-led technical launch page where the first viewport makes the product or offer immediately visible through typography, proof, and one actual product-state visual.

When To Use

• The user asks for a landing page, waitlist page, product launch, founder product page, or technical offer page with a premium or editorial feel.
• The user mentions DESIGN.md, Awwwards-level design, strong typography, minimal clean landing pages, or avoiding generic generated UI.
• The current page has bento sprawl, fake dashboards, decoration-first gradients, weak hierarchy, or a hero that hides the real product.

When Not To Use

• Dashboards, admin tools, CRUD tables, or repeated operational workflows.
• Ecommerce category pages, portfolio galleries, native app screens, or games.
• Broad brand strategy, logo work, or full design-system engineering.
• A task where the user wants to preserve an existing design system exactly.

Workflow

1. Read The Standard

Open references/DESIGN.md and extract:

• the visual thesis;
• the token values;
• the first-viewport rules;
• the typography roles;
• the anti-patterns.

Do not improvise a different style unless the user explicitly asks.

2. Lock The Product Signal

Before layout, identify:

• product or offer name;
• one short literal value proposition;
• one credible proof point;
• one real product-state image, screenshot, or generated bitmap specimen.

If no product-state visual exists, create or request one. Do not use decorative orbs, abstract SVG blobs, fake dashboards, or stock-like atmosphere as the main signal.

3. Compose The First Viewport

Build a first viewport that includes:

• a small navigation row;
• product name as the largest text on the page;
• one concise support paragraph;
• primary CTA and one quiet secondary link;
• proof metadata;
• the product-state visual as the background or main field, not a side card;
• a visible hint of the next section on desktop and mobile.

Use media queries for type changes. Do not use viewport-width font scaling.

4. Build The Page Rhythm

After the first viewport, add only the sections needed for the launch:

• proof strip;
• product/use-case band;
• interaction or detail band;
• CTA.

Keep page sections full-width or unframed. Use cards only for repeated proof or detail items, with radius 8px or less.

5. Verify Against The Bar

Check:

• text does not overlap at mobile or desktop widths;
• long words fit their containers;
• every accent color has a job;
• motion is optional and reduced-motion safe;
• the page implements the written design rules rather than describing them.

Output

For builds, produce the page and report the files changed plus verification run. For reviews, return findings first, ordered by severity, with references to the specific design rule that was violated.