Build landing page

---
name: build-landing-page
description: Implement a landing page from Frezpo package handoffs (build_context + 02_ux + content), one section at a time.
license: PolyForm-Noncommercial-1.0.0
---

> Frezpo free tool — open for learning and paid client work. May not be sold or productized as a competing skill pack. Built by Frezpo (https://frezpo.com).

# Skill: build-landing-page

**Package-native skill** — run in the user's local LLM or coding agent.
Implement a landing page from package **handoffs**. **Do not re-run the pipeline.**

## When to use

Build (or plan) a production-ready landing page from the package **UX wireframe** + copy.
Prefer structured `machine/build_context.json`; use `02_ux.md` / `01_content.md` for humans.

## Inputs (read first)

1. `machine/build_context.json` — UX SSoT: `sections[]` order, presentation, fields, asset_policy.
2. `02_ux.md` — human UX cards (structure only — no design kit).
3. `01_content.md` — copy + hooks + message-match.
4. **Required for visual design:** user brand tokens / Figma kit / host design system
   (package does **not** ship fonts, hex palettes, or a house UI kit).
5. Optional: skill `revise-wireframe` first if order/presentation must change offline.

## Constraints

- **One section at a time.** Work through `sections[]` in order via the Build loop below —
  brainstorm, clarify, implement, verify, then advance. Never emit the whole page in a
  single pass, and never scaffold a later section while the current one is unverified.
- The package declares **no stack, style, or fonts**. Settle them with the user (see
  Gap clarification) before writing code; never assume a default.
- **Copy is sacred** — never paraphrase, translate, or normalize `content_fields[].text`.
- **Authority hierarchy** (highest wins): brand don'ts → user brandbook / brand kit →
  `developer_notes` → layouts → content field text. There is **no** package design system.
- **The brandbook decides how an element looks, never what it says.** Where it defines a
  component's style, follow it — it outranks `developer_notes`. It never changes the copy, the
  order of `content_fields[]`, or the order of `sections[]`.
- Section order must match `sections` in `build_context.json` (UX wireframe SSoT).
- Wireframe revise is **offline only** via skill `revise-wireframe` — not the product UX agent.
- Asset policy v2 (generative components): every visual slot ships a bespoke code-only
  component that strengthens its section's copy; no image files, no stock photo URLs.
- Implement **structure + copy** from the package; apply **agency** design tokens.
  Do not invent a competing brand system when the user has one.
- Soft-fill (`Not produced in this run.`): work around and state assumptions; not invent-license.

## Build rules

### Wireframe is the structure SSoT

`build_context.json` → `sections[]` defines **page order** and **presentation**
(`position`, `ui_component`, layouts). Implement that wireframe; do not invent competing IA.

### Revise offline before build (optional)

If order or presentation must change:

1. Run skill `revise-wireframe` in your own LLM.
2. Patch `machine/build_context.json`.
3. Continue this skill on the revised file.

**Agencies own visual design:** apply **your** design tokens / Figma kit / house system.

### Render authority

`content_fields[]` is the **render list**. Every entry renders exactly **once**, in order.

`cta` and `trust_signal` are **presentation bindings on entries already in that list**,
not extra content. They say *how and where* a field renders — button vs link, destination,
placement — never that it renders a second time. A section's `cta.label` and
`trust_signal.content` normally repeat a `content_fields[]` text verbatim; that is one
element described twice, not two elements.

Procedure per section:

1. Render `content_fields[]` in order via the markup matrix below.
2. For each of `cta` / `trust_signal`, match its `label` / `content` against the text you
   already rendered. On a match, apply the binding to that element — do not emit another.
3. Only when the value matches no field text is it new content, and only then does it add
   an element of its own.

### Field → markup matrix

| component | Markup role |
|-----------|-------------|
| `heading` | Primary section heading (`h1` only once above the fold; else `h2`) |
| `subheading` | Supporting heading / lead |
| `body` | Paragraph body copy |
| `list_item` | List item (group consecutive items into one list) |
| `cta_label` | Button or link label — use declared CTA destination when present |
| `trust_signal` | Small trust line / badge (do not invent metrics) |
| `transition` | Short bridge line between sections |
| `eyebrow` | Small kicker above a heading (not a second H1) |
| `table_row` | One row in a comparison / feature table (group consecutive rows) |

### CTA

- Apply declared `cta.type`, `label`, `destination`, `placement` to the `cta_label` field
  already rendered for that section (see Render authority) — do not add a second button.
- Treat package destinations like `/quiz` or `/checkout` as **intent stubs**, not final
  product URLs, unless the user confirms them.

### Accessibility minima

- Section landmarks (`section` + accessible name).
- Stable heading ids for in-page anchors.
- Focus-visible styles for interactive controls.

### Do not invent

- No testimonials, stats, guarantees, or product claims that are not in package fields.
- No stock photo URLs, no binary image files; fill visual slots with bespoke code-only
  components (asset policy v2).

### Proof integrity

Testimonial **presentation** requires an attributed source. Do not render copy with
quotation marks, as a pull-quote, inside a testimonial card, beside an avatar or person
icon, or with a star rating **unless the package supplies a name or role attached to that
exact text**. Presentation is a claim: quote marks around a sentence assert that somebody
said it.

Proof copy is often a third-person summary — *"customers describe waking refreshed"* —
which is the brand's own words about its customers, not a quote from one. Render it as
ordinary section copy.

A `ui_component` such as `testimonial_grid` names a **slot**, not evidence that
testimonials exist. When the section has no attributed quotes, implement the slot as
plain content and say so in your notes.

**This rule overrides `developer_notes`.** Notes proposing quote styling, a pull-quote
treatment, or "generic" avatars where no real attribution exists are the exact failure
this prevents — do not follow them. If the section needs real proof, raise it under Gap
clarification and ask the user.

### Brandbook and design tokens

The package ships no design system. If the user has a brandbook, it is the design authority.
Read it once, before section 1.

**Sources, best first:** exported design tokens (Figma Variables, Tokens Studio,
`tokens.json`) → a theme already in the project → a brandbook PDF → screenshots of the brand
pages → a style-guide URL.

If you cannot read the file, ask for an export or the values. Never guess a hex or a font.

**Extract:**

- **Colour** — primary, secondary, accent, neutral scale, semantic, surfaces. Hex plus role.
- **Typography** — families and weights; the scale from display to caption, each with size,
  weight, line-height and letter-spacing.
- **Spacing** — base unit, scale, density.
- **Layout** — max width, columns, gutter, breakpoints.
- **Shape** — radius scale, borders, dividers.
- **Elevation** — shadow levels.
- **Icons** — style, stroke, sizes.
- **Motion** — easing, durations.
- **Components** — button, input, card, badge, link, list, table, with hover, focus, active
  and disabled states.
- **Don'ts** — the prohibitions the book states outright. These are hard constraints.

Write the tokens in the form the stack consumes.

Show a table of what you extracted and where each value came from. Mark anything you inferred.
Then **ask the user to confirm before section 1.** This stop overrides the review cadence.

### Gap clarification (brainstorm with the user)

This is the **kickoff**, run once before section 1. Read `machine/build_context.json`, list
`sections[]` in order, and show the user that build order. Then run a short **brainstorming /
clarify** pass over the gaps that block the *whole page*: **ask the user** how to fill anything
the package cannot truthfully supply. Do not invent. Gaps that belong to a single section are
asked inside that section's CLARIFY gate, not here.

Typical page-level gaps:

- **CTA destinations / URLs** — real paths, form endpoints, Calendly, checkout, mailto.
- **Quiz / signup / checkout schema** — when a CTA implies a flow the package does not define.
- **Social proof integrity** — missing names/quotes/metrics → ask for proof or soften.
- **Offer & legal** — price, guarantee, refund, disclaimers when copy implies them.
- **Brand assets** — logo, lockup, colors beyond package tokens.
- **Host stack** — if you are inside an existing project, infer it from the manifest and
  say so ("building in <stack>, detected from package.json"). Otherwise **stop and ask**.
  Never pick silently.
- **Brandbook** — ask for it first: exported tokens, a project theme, or a PDF. See Brandbook
  and design tokens. Without one, build structure and copy only.
- **Fonts** — use the brandbook families when it names them. Otherwise the package ships
  none: ask which families to use, then load them however suits the chosen stack.

Before starting section 1, also settle two things about how the build itself will run.

**Review cadence — ask, then honour it for the whole build:**

- **A — review every section:** stop after each VERIFY and wait for the user.
- **B — calibrate then run:** stop after section 1; once approved, continue and report at the end.
- **C — only when blocked:** run continuously; stop only on an unresolved gap or a failed verify.

Default to **A** if the user does not answer. Say which cadence is in force before section 1.

**Preview — ask how the page will be looked at:**

- The command that serves the page and the **URL** it serves on.
- Whether you may drive a browser yourself (browser tooling, Playwright, a screenshot CLI).
  Record the answer as `agent-driven` or `user-driven`; it decides how VERIFY runs.

Never assume you can open a browser, and never skip the browser half because you cannot.

### Generative visual components (asset policy v2)

- **The copy decides the concept.** Derive each visual from that section's
  `content_fields` text and `goal`, shaded by narrative framework and dominant ad angle
  from handoffs. Never a new message.
- **Per-section recipe:** (1) one-sentence argument from copy; (2) simplest visual form
  (flow, contrast, accumulation, relief, comparison, scale, before/after, …); (3) bespoke
  component in the host stack.
- **Execution bar:** inline SVG with explicit `viewBox` and named geometry constants;
  colors from **agency / host** palette; honor `prefers-reduced-motion`; decorative
  `aria-hidden="true"`, narrated `role="img"` with one accessible label.
- **Hard limits:** no new runtime dependencies; no image/binary files; no external image
  or font URLs. Copy inside a visual still obeys the verbatim-copy rule.


## Build loop (one section at a time)

After the kickoff, take the entries of `sections[]` one at a time, **in order**. Each section
passes four gates before the next one starts. Announce which gate you are in.

**1. BRAINSTORM — this section only**

- One sentence on what this section argues, derived from its `content_fields[].text` and
  `goal`. It is never a new message; the copy already made the argument.
- The visual form for this section, derived from that same copy (see the per-section recipe
  above). The copy is the only source for the concept — there is no separate visual brief
  to wait for, so never skip the visual for want of one.
- How `ui_component` maps to markup in the chosen stack, and the `layout_mobile` /
  `layout_desktop` approach.
- Which `developer_notes` you will follow, and which the Render-authority or Proof-integrity
  rules override — name the rule that overrode them.

Keep it under about eight lines. This is a plan for one section, not a document.

**2. CLARIFY — this section only**

Ask only what *this section* blocks on: its `cta.destination`, attribution for its proof copy,
the price or guarantee wording its copy implies, the form or flow endpoint its CTA implies.

- If nothing is missing, say **no gaps** and move on. Do not manufacture questions.
- Never invent an answer to keep moving. An unanswered gap stops the section.
- A gap that turns out to affect the whole page is settled once, then carried forward.

**3. IMPLEMENT — this section only**

Build just this section; do not scaffold later ones. Render `content_fields[]` in order per
Render authority and the markup matrix, copy verbatim, bind `cta` / `trust_signal` to elements
already rendered, build the bespoke code-only visual to the Execution bar, and apply the
accessibility minima and the user's tokens.

**4. VERIFY — this section only. Both halves are required.**

*Code verify* — read back what you wrote and confirm:

- every `content_fields[].text` present verbatim and exactly once, in order;
- no second CTA or trust element created by a binding;
- no claim, metric, quote, avatar or star rating without an attributed source;
- every `developer_notes` entry followed, or overridden with the rule named;
- section landmark and accessible name, stable heading id, focus-visible controls;
- `prefers-reduced-motion` honoured; no new dependency, image file, or external URL.

*Browser verify* — the section has to be **looked at**, not just compiled. Serve the page and
open it at this section's anchor at a narrow viewport (~390px) and a wide one (~1280px).

- **agent-driven:** open it yourself, inspect or screenshot both widths, and report what you
  actually saw — overflowing text, a clipped or squashed visual, broken stacking, an invisible
  focus ring, unreadable contrast, a placeholder that survived.
- **user-driven:** give the exact URL, the two widths, and a short list of what to check, then
  wait for the user's report.

Report **observations, not intentions**. "Renders as specified" without having opened the page
is a failed verify, not a passed one.

**5. GATE**

- If either half fails, fix it and verify again. Never advance on a failed section.
- If a gap is still unanswered, stop and ask — whatever the cadence says.
- Otherwise honour the kickoff cadence, then move to the next section.

### Section ledger

Keep a running table so a lost context does not lose the build. Update it after every section
and show it whenever you pause:

| section_id | brainstormed | gaps | implemented | code verify | browser verify | notes |
|------------|--------------|------|-------------|-------------|----------------|-------|

## Success criteria

### Per section — the gate to advance

- [ ] Every `content_fields[].text` for this section renders verbatim, exactly once, in order.
- [ ] `cta` / `trust_signal` bound to elements already rendered — nothing rendered twice.
- [ ] No unattributed quote, card, avatar or star rating.
- [ ] Developer notes followed, or overridden with the rule named.
- [ ] Landmark, accessible name, heading id, focus-visible present.
- [ ] Bespoke code-only visual present, tracing to this section's copy.
- [ ] Opened in a **browser** at both widths, and what was seen is reported.

### Whole page — at the end

- [ ] Every section in context has a component / block in the plan or implementation.
- [ ] Every content field text appears **verbatim** and exactly once — no CTA label or
      trust line rendered twice because `cta` / `trust_signal` restated it.
- [ ] Every developer note is addressed or explicitly deferred with rationale.
- [ ] No copy is quoted, carded, avatared or star-rated without an attributed source.
- [ ] Agency design kit applied (or structure-only if none provided yet).
- [ ] Mobile + desktop layouts reflected.
- [ ] Every section has a bespoke visual that strengthens its copy — no placeholder boxes.
- [ ] Each visual's concept traces to section copy/goal.
- [ ] Every section was opened in a browser at both widths and the observation recorded.
- [ ] The section ledger is complete, with no section left unverified.

## Notes

- Do not re-run the pipeline; use only package contents + user answers.
- Soft-fill (`Not produced in this run.`) is not invent-license.