Write Sales Page

---
name: write-sales-page
description: Write a sales page — one long-scroll page that sells ONE thing. Titles first (the full title chain designed before any body), then the sections under it. TRIGGER when a page's job is to close one offer in a single scroll. DO NOT TRIGGER for a page that trades for an email (write-optin-page), a page that lists several offers or pages (write-catalog-page), the spoken script behind a demo (write-vsl), or a standalone headline or lead (write-headlines, write-leads).
---

# Write Sales Page

One Process: design the full title chain first, because skimmers read only titles — the chain alone must tell the whole story of selling this one thing; then write each section under it.

Write under the plan's Reader.md, Brief.md, and Proof.md, and the product's Voice.md, which names the WHO speaking (founder, company, or champion); the whole page speaks in that one voice. The offer, its mechanism, and its proof come settled from the owner (draft-offers, mechanism); never assume an offer mechanism (trial, guarantee, urgency, anchor price) the owner has not approved, and never invent a number, quote, or customer.

## 1. Design the title chain before any body

The chain answers the reader's ordered BUYING QUESTIONS — real questions born of not understanding the product, in journey order — and marches as one argument to the CTA.

### Default to the structure readers expect
The chain and section order follow how a sales page is usually presented; creativity lives in the words, not the skeleton.
Evidence (owner, verbatim): "people are USED TO certain designs & us being creative in that sort of structure is almost always a terrible idea. we CAN use this as a surprise or to subvert expectations but in this case (& MOST cases) this is just a sloppy structure"

The sales-page skeleton (pick the beats the argument needs, in this order): hero (promise + subhead at the reader's stage) → picture-the-after (the vivid dream outcome in words, never dependent on an image) → problem agitated (end on the reader's limiting belief) → mechanism reveal (the named mechanism, honest because real) → solution as the mechanism (show the access shape) → what it does for them (outcome-first; features appear as a features section for ultra-aware readers, per copywriting's features law, which also holds the owner-open benefit form) → proof after each benefit and beside each CTA → price anchored to a REAL number (a competitor's cost, or the cost of inaction — never an invented struck-through price) → offer + price box + outcome-named CTA → risk reversal at the CTA → value framing anchored to the real alternative cost (not a bonus stack with invented retail values) → why-now that is real → FAQ → closing CTA (recap the promise, repeat the ask, re-attach the risk reversal) → legal footer.

### Write the chain as one argument marching to the CTA
Each title is a step the next advances — a problem title ANSWERED by a later solution title, closing on a resolution CTA title. A chain that skims as a list of topics fails even when every title passes alone.

### Head product sections with claim titles, proof and FAQ with carried questions
Claim titles are standalone, falsifiable, fifth-grade, and dead when a competitor's name is swapped in (the platitude test). Proof, trust, and FAQ sections take the reader's own first-person carried question, never a page-voiced "you" question. Never quiz or sentence the reader ("Do you actually know…", "What your setup can't show you is…"). An unrecognized problem is a body argument, never a heading.

### Run the mechanical checks on every title
No pronoun leaning on anything above ("it", "these numbers"); no page-geometry deixis ("the section below"); every title true and complete out of context; max two consecutive titles on the same opening subject; never raise an objection the reader does not carry yet.

If the chain departs in a big way from the expected sales-page structure, ship the departure only as a stated decision with its strategic reasoning attached.

## 2. Model the reader at each scroll position, then write the section

Three lines before writing each section: what they now believe, the loudest doubt, what they would leave over. The section contains only what moves that doubt and ENDS when the doubt is answered.

### Hold one Reader through the page
Every section assumes the same Reader — Reader.md's Audience, the named buyer — and each section answers the question the previous raised in that Reader. Never order sections by a teaching sequence instead of the chain of questions one held Reader actually asks.

### Name the Reader's motivation before writing any answer
Before an answer, name WHY the Reader asks; the answer serves that motivation and adds information beyond the question.
Evidence (owner, verbatim): "people asking this question need REASSURANCE. the anser gives none of that. (you need to ask WHY are people doing things & deeply understand EVERY action's motivation to write good copy)"

### One point per section
Never mix angles; pick the stronger and cut the other. People came for the software — side topics (the founder's story) get a sentence and a half.

### Answer result-first
A yes-question opens with "Yes" and the result the reader wants; mechanics get almost no space; developer language never reaches a non-developer reader.

### Carry the one belief shift as a story
At most one belief-shifting argument per page, and it arrives as a story, never a lesson (write-story produces the narrative component).

## 3. Draft as speech, then compress to sales register

Speak each section to one skeptical equal, transcribe, then compress hard: skimmable, tight, the conclusion arrives fast. No pseudo-conversation filler, no essays, no explanation-of-the-explanation, no teaching.

## 4. Hold the language bar

### Write fifth-grade words
A ten-year-old parses every sentence on one read. No cuteness, no coined nouns, no platitudes, no prose math (worked figures are design elements).

### Ban metaphors and metaphorical verbs
A verb states the literal action; a verb that imports an image makes the reader stop and interpret.
Evidence (owner, verbatim): "avoid metaphors AND metaphorical verbs; AIs tend to overuse BOTH in absurd quantities and it creates way too much unnecessary thinking & interpretation for the text"

### Be specific
Every claim, example, and figure is the specific one; a line that gestures at a category instead of naming the thing fails.
Evidence (owner, verbatim): "be specific. good copy IS specific."

### Punctuate for consumption, not grammar
Punctuation serves the reader's eye; drop grammatically correct marks that slow the read. No em dashes, no colon-drama, no contrast ticks ("X, not Y").
Evidence (owner, verbatim): "Copywriting is about making text EASY to consume, not adding every grammatically correct comma."

### Never narrate the reader
No "you"-assertion of what they do, have, feel, or pay. Reference the reader only through a first-person carried question, a subordinate time clause of visit-proven behavior, a generic subject, or the approved possessives. Never enumerate the reader's assumed app stack — one wrong guess poisons the page.

Late SaaS objections shape: [references/faq.md](references/faq.md).

## 5. Express visuals as design requirements

Enumerations of kinds, industries, or examples — and any content a visual carries better than prose (plans, worked figures, capability grids, pricing) — are a design requirement: the named visual plus the copy strings on it, never a prose list. Plans and pricing are shown, never summarized in prose. Output home: the deliverable's Wireframe.md, in the section's layout block.

Every section also carries a layout block — its section shape, where each element sits, and its CRO notes — written into Wireframe.md per the wireframe format in [references/wireframe.md](references/wireframe.md). Copy owns where things go and why; design owns how they look.
Evidence (owner, verbatim): "We need our copy team to be able to express requirements for design/images; otherwise they do stupid shit like that. No one is reading a paragraph listing a dozen industries."

## 6. Close forward

The close names the forward step — never rescuing the scene's own past artifact, never the hero's phrases, never the reader's failure as punchline, never a quotable clincher. The product's differentiation is spent exactly once on the page, by its owner section. Pain appears only where the product reduces it.

## 7. Wireframe the converged copy

Once the copy is locally clean, wireframe the finished page into the deliverable's Wireframe.md — section order, per-section rationale, a layout block per section, and the title chain — per the format in [references/wireframe.md](references/wireframe.md). This is a production output the writer owns; design works from it.

Verification: the bare title chain reads top to bottom as one argument selling one thing; every title passes the mechanical checks; the draft cites no unpermitted fact and contains zero banned strings; every section reads aloud as a person talking — before it reaches the gate.