# Wireframe Writer

> Use when planning the structure of a website page, landing page, or sales page for any niche or business — when you need a section-by-section wireframe aimed at one conversion. For critiquing an existing page, use wireframe-reviewer.

- Skill: `yaxeen/wireframe-writer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yaxeen/wireframe-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yaxeen/wireframe-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yaxeen (https://skillmd.com/u/yaxeen)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yaxeen/wireframe-writer

---


# Wireframe Writer

- A high-converting page is a story scrolled top to bottom: hero → problem → proof → offer → objections → action.
- This arc synthesizes the proven copywriting frameworks: **PAS** (problem–agitate–solve) drives sections 2–3, **AIDA** (attention–interest–desire–action) is the rising-conviction order, and **StoryBrand** supplies the stance — the visitor is the hero, the brand is the guide.
- Each section has one job and hands momentum to the next, the same way a video chains open loops.
- Built on the six levers — see **storytelling-hooks**. Recap: 1. Curiosity gap · 2. Emotional mirror · 3. Conflict engine · 4. Relatability · 5. Pattern + surprise · 6. Three-act.

## When to Use

- Planning a landing page, sales page, homepage, or product page structure.
- Turning an offer, product, or message into a section-by-section wireframe.
- Briefing a designer/developer with intent (the "why" of each block), not just boxes.
- Any niche or business. For reviewing an existing page, use **wireframe-reviewer**.

## Intake (Before Wireframing)

- Confirm: the offer and its one conversion action, exact audience (who buys, in one sentence), traffic source, and available proof assets (testimonials, numbers, logos, case results).
- **Use the traffic source:** cold arrivals (ads/social) need a heavier problem section and more proof; search arrivals already feel the problem — tighten the top and get to mechanism and offer sooner.
- Ask if missing when the user can respond; otherwise state assumptions explicitly at the top and proceed — never invent proof or numbers.

## Output Format

- Read **patterns.md** (same folder) for headline, problem-opener, mechanism, CTA, and objection copy-direction structures — adapt, don't copy.
- For each section, specify three things:
  - **Job** — what this section must accomplish.
  - **Message** — the core line/idea (copy direction, not final copy).
  - **Lever** — which storytelling lever it pulls.

## Page Arc (Quick Reference)

| # | Section | Job | Lever |
|---|---------|-----|-------|
| 1 | Hero | Hook + promise + primary CTA | 1, 4, 2 |
| 2 | Problem / agitate | Name the pain, make it "me" | 3, 4 |
| 3 | Solution / mechanism | Show the path out | 6 |
| 4 | Proof | Make the claim believable | — |
| 5 | Benefits / outcomes | Paint the after-state | 2 |
| 6 | Offer | What they get, clearly | — |
| 7 | Objections / FAQ | Remove the last "but" | 3 |
| 8 | Final CTA | One action + bookend | 1 |

## Section Playbook

- **Hero:** headline = curiosity gap + promise; subhead clarifies; one primary CTA above the fold. Don't bury the hook in branding.
- **Problem/agitate:** mirror the reader's pain so they think "this is me" (relatability + emotional mirror). The conflict engine starts here.
- **Solution/mechanism:** introduce the path/method — the "how it works". This is the resolution turn of the three-act.
- **Proof:** testimonials, logos, data, before/after, screenshots. Both a dedicated proof section *and* proof distributed beside individual claims — the section carries the weight, the inline pieces defuse specific doubts.
- **Benefits:** outcomes and the after-state feeling, not feature lists. One idea per block.
- **Offer:** make exactly what they get unmissable — components, price, terms.
- **Objections/FAQ:** pre-empt the self-made obstacles ("too expensive", "won't work for me", "no time").
- **Final CTA:** restate the promise (bookend the hero), one action, remove friction.

## Conversion-Flow Rules

- **One primary action** per page; repeat the same CTA, don't introduce competing ones.
- Each section should leave a small open loop pulling the scroll downward.
- Order by rising conviction: hook → relevance → belief → desire → action.
- Match section length to its weight; cut anything that doesn't move toward the CTA.
- CTAs repeat at natural decision points (after hero, after proof, at the end).

## Common Mistakes

| Mistake | Fix |
|---------|-----|
| Hero about the company ("Crafting Digital Experiences") | Hero about the visitor's outcome, in their words |
| Proof stacked in one distant section | Distribute proof beside the specific claims it supports |
| Every section same length and weight | Size sections by their persuasion weight; cut ruthlessly |
| Navigation full of exits on a landing page | Strip or minimize nav — one page, one action |
| Desktop-only thinking | Hero + CTA must work in a single mobile viewport |
| Proof or numbers invented to fill the template | Use only real assets from intake; mark gaps as "needs proof" |

## Wireframe Checklist

- [ ] Does the hero hook + promise + show one CTA above the fold?
- [ ] Is the reader's problem mirrored so it feels personal?
- [ ] Is there a clear solution/mechanism turn?
- [ ] Is proof placed beside the claims it supports?
- [ ] Are benefits framed as outcomes/feelings, not features?
- [ ] Are top objections pre-empted before the final CTA?
- [ ] One primary action, repeated — no competing CTAs?
- [ ] Does the final section bookend the hero's promise?
- Each section answers: what's its job, what's the message, which lever?

## Related

- **wireframe-reviewer** — critique an existing page against this arc.
- **storytelling-hooks** — the six levers (read for depth).