Proof

Proof

A product design skill. A proof is the first copy off the press: good enough to ship, then adjusted by hand.

The goal: a first draft that looks like a shipped product page, not an AI template.

Everything here was learned from 400+ real product pages. The skill decides who the page is for and which sections earn their place, then builds it in a style with its own character — a signature hero, a real-looking product with motion, varied section layouts, real logos, and finished sample content where the user gave none. Before delivery it checks its own work and reports what it filled in.

Scope: marketing website pages (8 page types, 10 standalone sections). Not app UI, dashboards, or multi-page flows. All knowledge is embedded — works offline, no external services.

Paths: every path in this skill is relative to the folder containing this file. Inside a page skill, references/... means that page skill's own references/ folder.

Quick Start

Copy code
/proof                          → short design conversation, then a page
/proof landing                  → generates right away (Minimal, light)
/proof pricing editorial dark   → page type + style + theme
/proof hero colorful            → a single section

Arguments can come in any order. Accepted values:

product is the Product page; features is the Features section.

Depth: the user decides how much to give

Never ask for more than the current level needs. Each level uses everything the user already gave.

Expert controls — honor any of these when the user states them, without asking for confirmation:

• Archetype by name or letter, e.g. "pricing, archetype B" or "usage-based pricing" (names below)
• Sections: include, exclude, or reorder ("no FAQ", "put social proof second", "add a comparison table")
• Layout pattern for a section, when the section skill offers several ("features as a bento grid")
• Brand tokens: accent hex, display font
• Output: standalone HTML or the project's stack (Step 4.7), file name, location
• Motion: "no animation" removes all optional motion

Step 1 — Pick the route

Fast route — the request names a page type or section (as an argument or in plain words). Do not ask questions first.

• Use whatever the conversation already says about the product, audience, and content.
• Style: the argument, else a recommendation from context (see Step 2 logic), else Minimal. Theme: the argument, else Light.
• Choose the archetype from available signals; with no signals, use the page skill's default archetype.
• Page skills list some inputs as "Required — ask". That applies to the guided route only; on the fast route, a missing required input becomes sample content like any other missing material. The only bracket placeholder allowed is the product name, and only when the user gave none ([Product]). Never put brackets in the nav, footer, or legal line: the copyright line is © <year> <product name>.
• Generate (Step 4). Copy written from what the user said (headline, subtitle, feature framing) is fine. Material the user didn't give — testimonials, customer logos, metrics, certifications, team, feature specifics — becomes sample content (see Sample content in Design Rules), so the page is full and easy to react to.
• After delivery, offer the next level in two or three lines: the 2–3 questions from Step 2 whose answers would change this page's structure most (e.g., "No testimonials yet? I'll drop Social Proof and lead with How It Works."), plus one line noting that archetype, sections, style, and brand can be set directly.

Guided route — no page type and the request is too vague to act on (e.g., "make me a website", or just a product name).

• Ask one round of questions, grouped in a single message. Include the content questions from Step 3 in that same round. Never ask a second round before generating.
• After the answers, show the compact proposal (Step 2), then generate in the same turn. Ask instead only if the page type itself is still unclear.

Explicit user preferences always override recommendations.

Step 2 — Brief and recommendation

What to learn (ask or infer; skip anything already clear)

1. What and who — "What are you building, and who is this page for?" → page type, explanation depth, archetype, language register.

2. Goal — "What should someone do after seeing this page?" → primary CTA, page length, urgency. "Sign up free" and "book a demo with sales" produce different pages.

3. Barriers — "What might stop them?" → which objection-handling sections to include and where. Integration effort → How It Works / integrations. Trust → social proof early.

4. Evidence — "What real materials do you have — screenshots, customer quotes, metrics, case studies?" → what is real. Given material is used as-is. If the user says they have none of something ("no testimonials yet"), leave that section out. If the user doesn't mention it, include the section with tagged sample content.

5. Brand — "Any brand colors, fonts, or visual direction?" → style recommendation and overrides. Accept a hex code + font name, or a pasted brand guideline (extract automatically).

Don't ask design-jargon questions ("which archetype?"), questions whose answers wouldn't change the page, or anything already answered.

Proposal format

Copy code
Project:   [product] — [one-line description]
Audience:  [who visits, what they know]
Goal:      [primary action]
Barrier:   [main concern]
Evidence:  screenshots ✓ / testimonials ✗ / metrics ✗

Page:      Landing Page
Style:     Minimal · Dark
Approach:  Problem explanation → product visual → sequential workflow
           → integration section → FAQ → CTA
Skipping:  Social Proof (no testimonials), Stats (no real data)
Brand:     [#hex] · [font] (or "style defaults")

Recommendation logic

Page type — from the user's goal:

• Presenting a product to new visitors → Landing
• Explaining plans and pricing → Pricing
• Collecting inquiries or support requests → Contact
• Telling a company/team story → About
• Deep-diving into features for evaluators → Product
• Publishing articles → Blog
• Handling missing routes → 404
• Distributing installs → Downloads
• Several pages requested → build them one at a time with shared brand context.

Style — from audience and tone, not product category:

• Technical precision, developer audience, "let the product speak" → Minimal
• Enterprise B2B, trust and reassurance, warm professionalism → Business
• Creative tools, consumer products, personality and warmth → Colorful
• AI/research, editorial authority, content depth → Editorial
• "B2B" alone doesn't mean Business. A developer tool sold to enterprises may be Minimal; a consumer AI product may be Editorial.

Theme — Light unless the product is developer- or code-heavy, or the user wants dark. Editorial has built-in dark hero/CTA sections in either theme.

Section decisions — where the brief earns its value:

Carry these decisions into the page skill's archetype selection and section composition. They change what the page contains and its order, not just its copy.

Step 3 — Content (asked inside the Step 1 question round, never separately)

Everything not provided becomes tagged sample content (Design Rules → Sample content), except what the user said they don't have.

• Landing: 3 key features (name + one sentence). Optional: company names for a logo strip.
• Pricing: 2–3 plan names and prices, 3–5 features per plan. Optional: billing toggle, trial language.
• Contact: primary email. Optional: location, phone, department names.
• About: mission (1–2 sentences). Optional: team (name + role, up to 8), stats, founding year.
• Product: 3–4 capabilities. Optional: audiences, integration names.
• Blog: 4–6 article titles with categories. Optional: featured article.
• 404: nothing needed.
• Downloads: platforms (macOS / Windows / Linux / iOS / Android). Optional: install command.

Step 4 — Generate

1. Read the active style file in full, to the last line (Appendix). It is the visual foundation. Its last section, Style Signature, is mandatory, not decoration:

   • The hero uses the style's Hero showcase (its backgrounds and textures come from shared/atmosphere.md) unless the user asks for a different hero or the page skill's archetype has no hero (404, single sections other than hero). Start from the showcase's HTML example and keep its class names (.specimen-field, .biz-stage, .hero-scene, .ed-stage); the self-check looks for them. The Style Signature replaces the page skill's hero layout (its centered stack, M3, etc.); keep the page skill's hero content rules (headline, CTAs, archetype copy).
   • Use at least two of the style's Signature details across the page.
   • Follow its Motion personality and Drift guard; before delivering, run its Screenshot test against the page.

2. Apply Style precedence (below) before opening the page skill.

3. Plan the page's craft before writing code — do this once the page skill (item 5) has chosen the archetype and section list, and before any section is built:

   • Read shared/signature-moves.md. Choose the page's signature moves (§5 selection guide) and write a section plan: each section with its data-layout, data-bg, and data-bold. The plan must pass rules R2–R6: no two adjacent sections share a layout, background changes at roughly every other boundary, 1–2 bold sections (0–1 on Pricing, Contact, 404, Downloads), at most one equal-card grid. Layout precedence: when a page skill's default layout would repeat the previous section's layout, use that section's alternative pattern or a catalog move instead.

   • Style layout defaults. Styles must differ in structure, not only in color. Unless the brief or the user says otherwise, build the main sections with the active style's defaults (moves from shared/signature-moves.md):

     Section role	Minimal	Business	Colorful	Editorial
     Hero	Specimen Field (§12.2)	Framed product stage, M4 + M3 (§10)	Scene panel, M4 (§10)	Full-bleed dark stage, M4 (§10)
     Features	M16 feature rows: split-left / split-right alternating, mono index labels (01 · Ownership), the product fragment at 7/12 width on a surface-1 mat	M5 bento (flat surface-1 lead tile — the mesh stays in the hero), then 1–2 M16 rows on alt	Scene chapters: M16 rows, one major feature per split-left / split-right section, the second chapter inside a scene	260px margin column with the section heading; M16 rows (or M8 sticky chapter tabs) in the wide column
     Steps / how it works	M15 step tiles, surface-1 mats, mono step numbers	M15 step tiles as shadowed .cards (M9 step rail when the product turns inputs into an output)	M15 step tiles: paper panels on one scene mat	M15 step tiles as ruled .card-statics in the margin-column layout
     Proof	logo-row (varied sample wordmarks); quotes as M17 quote wall, or M10 for one real quote	M17 quote wall of #FFFFFF shadowed cards on alt, or M11 stat bento with real numbers	M17 or M10 inside the second scene	the mid-page dark band (.ed-band, data-bg="dark"): M17 ruled cards or an M10 poster quote
     Closing	Left-aligned CTA (large heading, buttons below — Twingate, Notion); M14 wordmark footer only for a short-named consumer or creative brand	centered-stack CTA	CTA inside a scene	Dark stage CTA

     Then apply R2–R6. If a default would repeat the previous section's layout, take the next row's layout or swap split sides.

   • If the page has a product visual (hero, features, bento), read shared/product-visuals.md and pick a recipe for each visual. No grey skeleton bars or empty boxes as a main visual.

   • Read shared/copy.md before writing any headline, heading, or button label.

4. Read shared/interaction-patterns.md selectively: §1 Motion Tokens, §1.5 Product-Serving Motion (whenever there is a data-mock visual), §13 Page-Type Animation Map, and §11 Mobile Nav Toggle (every page with a nav needs it), then only the recipe sections the map lists for the sections on this page (and §14 Combined Script Template when using three or more patterns). All motion is a progressive enhancement inside prefers-reduced-motion.

5. Read the page or section skill (Appendix) and follow its workflow, carrying the brief forward. After its archetype and section-composition steps, do item 3 (craft plan), then continue with its build steps:

   • Archetype selection uses the brief's audience and goal signals, not just product category.
   • Section composition applies the Step 2 decisions: skip sections whose evidence is missing; add sections that answer stated barriers.
   • Where a section has several layout patterns, pick the one that fits the brief (workflow layout for sequential value, card grid for parallel features).

6. Brand overrides (only if provided):

   • Color → --accent: [hex]; --accent-text: [white or black for contrast]
   • Font → --font-display: '[Name]', [fallback] + Google Fonts <link>
   • None → keep the style preset's values exactly.

7. Output:

   • Default: one self-contained .html file (all CSS in <style>, all JS in <script>, responsive, no dependencies except Google Fonts), named [product]-[page-type]-[theme].html, in the working directory unless the user names a location.
   • If the user asks to add the page to their project (React, Next.js, Vue, Svelte, Astro, Tailwind…), build it in that stack instead: style tokens as CSS custom properties in the global stylesheet (or the Tailwind theme when Tailwind is present), one component per section, same structure and design rules.
   • Single-section requests: output that section alone inside a minimal HTML shell (fonts, tokens, base styles), with no nav or footer unless the user asks; measure the hero's top whitespace from the top of the page.
   • If the working directory is clearly a frontend project and the user didn't ask for integration, deliver the HTML file and offer the port in one line.
   • Markup conventions (they let the self-check verify structure; harmless in production):
     • <html lang="en" data-page="pricing" data-archetype="A" data-style="business" data-theme="dark">. For a single section, use data-page="section" and omit data-archetype.
     • Put data-section="<name>" on the nav, on every top-level section, and on the footer. Names: nav, hero, page-header, logo-wall, problem, features, feature-showcase, how-it-works, use-cases, integrations, security, social-proof, stats, comparison, pricing, billing-toggle, enterprise, faq, cta, newsletter, story, team, values, timeline, careers, contact-form, contact-info, departments, featured, filter, articles, pagination, error, recovery, platforms, install, versions, footer. Testimonials and customer quotes are social-proof; customer logos are logo-wall. A section mainly about security or compliance is security; one that explains the problem before the product is problem.
     • Put data-logo-source on every logo (see Real logos only in Design Rules).
     • Put data-layout, data-bg, and (for signature moves) data-bold="true" on every content section. Use only the tags in shared/signature-moves.md §2.2 and the roles in §2.3 — never a custom name (grid-3col, split, default fail the self-check).
     • Put data-mock on the outer frame of every synthetic product visual. Data inside a mock (rows, counts, timestamps) is illustrative UI, not a claim.

8. Verify — before showing anything to the user:

   • If python3 is available, run python3 <this skill's base directory>/scripts/check_page.py <file> --style <style> as a single command — absolute path, no cd first, so it matches the pre-approved python3 permission. Fix every ERROR. Fix each WARN too unless it is deliberate (a brand override, colors inside a synthetic product mock) — then say why in the QA report.
   • Run the page skill's Step 6 checks. With project-stack output, run the checks that apply by reading the code.
   • Copy check: run the self-check list at the end of shared/copy.md (sentence case, concrete nouns, no banned phrases, at most one AI word per headline).
   • Claims check: list every factual claim on the page — numbers, customers, certifications, integrations, awards, speed/ease/result promises. For each, point to where the user said it. Any claim without a source must be inside a data-sample element; otherwise tag it or remove it.

9. Deliver: open the HTML file in the browser when running locally (open <file> on macOS, xdg-open on Linux, start "" <file> on Windows). Then give:

   • the file name, and a 2–3 sentence note on the key design decisions (archetype, what was skipped and why);
   • a short QA report:

     Copy code
     QA
     - Self-check: 21 passed · 0 errors · 1 warning (product mock uses 3 colors outside the style file — intentional)
     - Claims check: 9 claims · 6 from your brief · 3 tagged as sample
     - Sample content to replace or remove: testimonials (3, fictional), logo wall (5 fictional wordmarks), "SOC 2" card
     - Placeholders to replace: [Company], plan descriptions
     - Left out: Stats (you said there are no real numbers yet)
     - Values with no style role: price 48px (kept from the page skill)
     

     If Python isn't available, write "Self-check: not run (no Python 3); page skill checklist reviewed".
   • on the fast route, the brief offer from Step 1.

Style precedence

Page and section skills were written against Minimal. Their inline token blocks, Step 6 checks, and references/anti-patterns.md files contain Minimal values (2px buttons, zero shadow, 180px section rhythm, DM Sans 500 headings, "no pill buttons"). When Business, Colorful, or Editorial is active:

1. Visual values come from the active style file — fonts (including its Google Fonts <link>), weights, colors, radius, shadow, spacing rhythm, transition timings (§6), and button / input / nav / card styling. Map each Minimal value to the role with the same name in the active style file (§2 type scale, §3 spacing, §4 radius, §5 shadow, §6 transitions, §8 components). Example: a page skill's "feature card 8px radius" becomes Business "Feature card: 16px". References to visual-style.md §10 (brand customization) mean the active style file's Brand Customization section.
   • Page frame: the grid max-width and side padding (§7) and the nav height --nav-h (§8) come from the style file. A page skill's "1080px container" means "the style's main grid". Narrower measures a page skill sets inside that frame (a 720px reading column, a 540px subtitle) stay.
   • Page headers on pages other than Landing (pricing, blog, contact, about, downloads headers) use the style's hero top whitespace and its "Cross-page hero" size when the style defines one (Editorial does); otherwise its section heading size, unless the page skill explicitly asks for hero scale.
   • Section padding in every style file is the top and bottom padding of each section, as in Minimal; the visual gap between two sections is twice that value.
   • Borrowed Minimal values: when a page skill reuses a named Minimal token for another gap (58px = heading to content, 128px = hero top / footer top, 180px = section padding, 32px = card padding), map it to the same role in the active style (e.g., a 58px CTA-to-visual gap becomes Business 48px).
   • Buttons: Minimal's .btn-lg (16px · 12px 24px) exists because Minimal's default button is 14px. Business, Colorful, and Editorial default buttons are already 16px — use their default button where a page skill asks for .btn-lg.
   • Product visual frame: the Synthetic Product Visual's outer frame takes the style's content-card role (Business content card 24px, Colorful scene frame 24px, Editorial product stage 22px). Business's 48px "product stage panel" is for large nested containers, not screenshot frames.
   • Dark bands: .section-dark / a var(--text) background is a Minimal technique. In other styles, use the style file's own section-background rules (Business "Section Backgrounds", Colorful "Scene Section", Editorial "Section Background Switching"). On a dark-theme page, never flip a footer or CTA into a var(--text) band — that color is light there.
2. Structure comes from the page skill — archetype, section list and order, content rules, layout (column counts, component anatomy), interactions, and page-specific measurements with no role in the style file (e.g., the Downloads 64px app icon). The Synthetic Product Visual recipe in shared/visual-style.md §8 is structure too: use its frame / chrome bar / panel layout in any style, with the active style's surfaces, radius, and shadow.
3. Minimal-only rules are replaced, not combined. Zero-shadow, no-pill-button, 2px-button, sans-only-heading, 180px-rhythm, and achromatic-color rules (in page skills, checklists, and anti-patterns files) give way to the active style file's own rules. So do generic palette bans (e.g., "no cream + terracotta") when the active style defines that palette on purpose. Content and structure rules — no fabricated evidence, section order, nav present — apply in every style.
4. No matching role? Keep the page skill's value and mention it in the delivery note. Don't invent a new value.

Lookup aid — the style file is authoritative:

Design Rules

These override any competing instruction in referenced files, in every style:

• No left-border accents on cards. Never use border-left as a status or category indicator — it reads as AI-generated. Use opacity or background color.
• Sample content fills gaps; the QA report names it. Material the user didn't give is never passed off silently. That covers testimonials, customer names and logos, user counts, revenue, metrics, certifications (SOC 2, HIPAA, ISO), security specifics (TLS 1.3, AES-256, SSO, SCIM), awards, integration names and counts, trial lengths and plan terms, deployment options, data-center regions, and claims about speed, ease, or results ("set up in minutes", "no learning curve", "2× faster"). When such material is missing:
  • If the user said they don't have it, leave the section out.
  • Otherwise, fill the section with sample content so the page is not empty: realistic in shape, obviously fictional in substance. Use fictional companies and people, round illustrative numbers, and wordmarks — never real customer logos. Invent the companies for each page: 5–6 names that sound like real small companies in the user's market — coined words, surnames, or places (Halberd, Larkspur, Quarry & Co, Fernhill, Brightmoor, Tidewell). Never use the well-known placeholder set (Northwind, Contoso, Fabrikam, Globex, Initech, Acme, Umbrella, Hooli): readers recognise them as fake at a glance. Do not pick a famous real brand by accident. Sample logo walls follow sections/social-proof/SKILL.md Sample wordmarks.
  • Sample content must look finished — same polish as real content, no visible "sample" labels, no grey boxes or [brackets] where real-looking content fits. Completeness and visual quality of the first draft come first; the user edits the content afterwards.
  • Put an invisible data-sample attribute on every sample section or element (including product claims inside otherwise real sections, e.g. a "SOC 2 certified" card or a "100+ connectors" line).
  • List every sample item in the QA report so the user knows exactly what to replace or remove.
• Tokens are quoted, not authored. Spacing, type scale, colors, and radii come from the active style file. If a value is missing, flag it — don't invent one.
• Fixed nav requires backdrop blur. backdrop-filter: blur(12px) on every fixed nav.
• Directional padding only. Use padding-top (not the padding shorthand) when overriding one direction on an element that inherits .container's horizontal padding.
• Respect prefers-reduced-motion. All CSS animation inside @media (prefers-reduced-motion: no-preference) { ... }.
• Real logos only — never draw one. This covers every third-party mark: integration logos, customer logo walls, platform icons, social icons. Take each logo from the first source that has it:
  1. If an icon MCP is connected (e.g. better-icons), fetch the SVG from the Iconify logos collection (full color) or simple-icons (monochrome) and inline it.
  2. Otherwise use an image URL: https://api.iconify.design/logos/<name>.svg (full color, e.g. logos/slack-icon, logos/notion-icon) or https://cdn.simpleicons.org/<slug> (brand color; append /<hex> for one color, e.g. a grayscale logo wall). If you can run commands, confirm each URL returns 200 first. Give every logo <img> a wordmark fallback: onerror="this.replaceWith(Object.assign(document.createElement('span'),{textContent:this.alt,className:'logo-wordmark'}))".
  3. If neither library has the brand, set the brand name as a text wordmark in the display font. Mark every logo element with data-logo-source: iconify:<collection>:<name>, simple-icons:<slug>, user (a file the user supplied), or wordmark.

Appendix — File Routing

Style files

Page skills

Section skills

Use when the user asks for a single section rather than a full page.

Shared