Landing page generator

Landing Page Generator

Version: 2.0.1 Type: Multi-phase pipeline with human review gates Model: opus (all phases) Depends on: modules/conversion-playbook.md, modules/campaign-brief-template.md, modules/lp-audit-taxonomy.md (construct mode), modules/section-taxonomy.md, templates/section-catalog.html

Agent Model Selection

Agent	Phase	Runs as	Model
Brief Builder	1	Subagent (Task tool)	opus
Copy Agent	2	Subagent (Task tool)	opus
Design Agent	3	Subagent (Task tool)	opus
QA Validator	4	Inline in orchestrator	opus (session model)

Sonnet was tested repo-wide and produced worse output (hallucinated facts, inflated claims) for marginal savings; all agents stay on Opus per the repo convention.

Generates B2B paid landing pages from existing positioning context. Four phases: Brief Builder, Copy Agent, Design Agent, QA Validator. Each phase produces a file that the next phase consumes.

---

Invocation

/landing-page-generator <company-url-or-name> <campaign-slug> [--stage <stage>] [--depth standard|deep]

Arguments:

• <company-url-or-name>: Company URL or name. Must match an existing .claude/context/company-identity.md OR be resolvable to one.
• <campaign-slug>: Kebab-case campaign identifier (e.g., interim-cfo, erp-implementation, audit-readiness).
• --stage: Run a single phase. Values: brief, copy, design, qa, all. Default: prompt user.
• --depth: Controls copy depth. standard (default) produces 3 headline options + full section copy. deep adds variant copy for A/B test sections.

Examples:

/landing-page-generator acme interim-cfo --stage brief
/landing-page-generator acme interim-cfo --stage copy
/landing-page-generator acme interim-cfo --stage design
/landing-page-generator acme interim-cfo --stage qa
/landing-page-generator acme interim-cfo --stage all

---

Preconditions

Hard requirements (fail if missing):

• .claude/context/company-identity.md must exist with confidence >= 3. If missing, report [PRECONDITION FAILED]: Run /positioning-framework first to build company context.

Soft requirements (degrade if missing):

• .claude/context/audience-messaging.md -- needed for persona messaging, proof points, voice. Without it, brief builder must ask the human for all persona and proof data manually.
• .claude/context/competitive-landscape.md -- used for competitive framing in copy. Without it, skip competitive positioning sections.
• .claude/context/positioning-scorecard.md -- used to identify gaps. Without it, skip gap-based recommendations.
• .claude/deliverables/ -- executive summary, messaging guide, battle cards. Used to enrich brief building. Without them, rely on L0+L1 context files only.
• .claude/context/performance-profile.md -- used to inform keyword strategy and page pillar prioritization. Without it, ask human for all keyword and traffic data.

---

Output Location

All campaign outputs go to:

.claude/deliverables/campaigns/<campaign-slug>/
  brief.md          # Phase 1 output
  copy.md           # Phase 2 output
  page.html         # Phase 3 output
  qa-report.md      # Phase 4 output

---

Orchestrator Logic

Step 1: Parse Arguments

Extract company identifier, campaign slug, stage flag, and depth flag. Validate campaign slug is kebab-case (lowercase, hyphens only, no spaces).

Step 2: Resolve Company Context

Glob .claude/context/ and read frontmatter of all files found. Build an inventory:

File	Status	Confidence
company-identity.md	present/missing	1-5
audience-messaging.md	present/missing	1-5
competitive-landscape.md	present/missing	1-5
positioning-scorecard.md	present/missing	1-5
performance-profile.md	present/missing	1-5

Also glob .claude/deliverables/ for rendered deliverables (executive summary, messaging guide, battle cards).

If company-identity.md is missing or confidence < 3: stop. Print [PRECONDITION FAILED] with instructions to run /positioning-framework first.

Step 3: Prior Work Detection

Check if .claude/deliverables/campaigns/<campaign-slug>/ exists. If it does, read frontmatter of any files present:

• If brief.md exists and user requested --stage brief: ask "A brief already exists for this campaign. Overwrite, extend, or skip?"
• If copy.md exists and user requested --stage copy: ask "Copy already exists. Overwrite or skip?"
• If page.html exists and user requested --stage design: ask "HTML page already exists. Overwrite or skip?"

Never silently overwrite. Always ask.

Step 4: Route to Phase

If --stage is specified, run that phase only (with precondition checks). If --stage all, run the full pipeline with human review gates between each phase. If no --stage flag, ask the user:

"Which stage do you want to run?"

• Brief (Phase 1): Build the campaign brief from positioning context
• Copy (Phase 2): Generate landing page copy from the brief
• Design (Phase 3): Build HTML page from the copy
• QA (Phase 4): Validate copy and HTML against the playbook
• All: Run the full pipeline with review gates between stages

Step 5: Launch Phase Agent

Each phase runs as a subagent. Load:

1. agent-header.md (shared rules, ~1.5K tokens)
2. The relevant phases/<phase>.md file
3. Any modules referenced by that phase

Phase routing:

Stage	Agent loads	Preconditions
brief	agent-header.md + phases/brief.md	company-identity.md confidence >= 3
copy	agent-header.md + phases/copy.md + modules/section-taxonomy.md	brief.md must exist in campaign directory. Optionally reads brand-design-system.md from context directory (Step 3.5 component matching).
design	agent-header.md + phases/design.md + templates/section-catalog.html OR brand-components.html	copy.md must exist in campaign directory. When brand-components.html exists in context directory, it replaces section-catalog.html as the section catalog.
qa	agent-header.md + phases/qa.md + modules/section-taxonomy.md	At least one of copy.md or page.html must exist

Step 6: Review Gate (--stage all only)

After each phase completes:

1. Present a summary of what was produced
2. Ask the human to review and confirm before proceeding
3. If the human requests changes, re-run the phase with their feedback
4. Only advance to the next phase after explicit confirmation

Phase 1 complete. Brief saved to .claude/deliverables/campaigns/{slug}/brief.md
Review the brief. When you're ready, say "continue" to generate copy, or tell me what to change.

Step 7: Completion

After the final phase (or single phase), summarize what was produced:

• Files written (with paths)
• Any gaps or warnings flagged during execution
• Next step recommendation

---

Token Budget

Phase	Estimated Tokens	Notes
Brief (Phase 1)	~50-80K	Reads L0+L1 context, interactive gap filling
Copy (Phase 2)	~90-145K	Reads brief + playbook module + taxonomy construct mode (D1,D2,D3,D5,D7,D8,D10) + section-taxonomy.md (section selection logic) + positioning context. +10-15K when brand design system detected (Step 3.5 component matching).
Design (Phase 3)	~105-165K	Reads copy + structural rules + taxonomy construct mode (D4,D6,D9) + section catalog (brand-components.html when present, otherwise section-catalog.html) + brand design system tokens
QA (Phase 4)	~35-55K	Validation pass (includes composable section checks) + section-taxonomy.md (ordering constraint validation)
Full pipeline	~280-455K	All four phases with review gates. Upper bound includes brand component overhead.

---

Design Decisions

Why separate phases instead of a single agent? LP generation has natural human review points. You review the brief before writing copy. You review copy before building HTML. Forcing this into a monolithic agent with checkpoints adds complexity for zero benefit. Separate phases also mean you can re-run Phase 2 (copy) without re-running Phase 1 (brief) after the brief is finalized.

Why consume .claude/context/ directly? The positioning-framework skill produces structured context files with frontmatter. This skill reads them directly instead of maintaining a parallel client directory. No manual file copying. The positioning-framework IS the client onboarding step.

Why outputs in .claude/deliverables/campaigns/? Campaign briefs and copy are deliverables, not reusable analysis context. They are campaign-specific and consumed by exactly one downstream phase. Putting them in .claude/context/ would be a layer violation. The campaigns/ subdirectory keeps multiple campaigns organized under one client's deliverables.

Why composable sections instead of a fixed wireframe? The fixed wireframe produced identical page structure for every campaign regardless of context. The composable section system selects and sequences sections based on campaign brief signals and L0/L1 context, producing different page compositions for different campaigns. The section taxonomy is the shared reference; the section catalog is the visual reference for the design agent.

Why templates/ for the section catalog? The section catalog is an HTML visual reference used by exactly one phase (design). It lives in templates/ within the skill directory because it is skill-specific, not cross-skill. The legacy wireframe (wireframe-demo-legacy.jsx) is retained in the same directory for reference only.

Why does brand-components.html replace section-catalog.html, not supplement it? The brand component library contains client-specific HTML/CSS patterns that must be used as-is for brand compliance. Using the generic catalog alongside it would give the design agent two competing pattern sources. The brand library is authoritative when present. The generic catalog exists for clients without brand context.

Why is component matching semantic rather than explicit mapping fields? Brand design system files are produced by a separate skill that extracts from Figma, Brandfetch, and other sources. Adding taxonomy mapping fields would couple that skill's output format to the LP generator's section taxonomy. Semantic matching (the copy agent reads component names, capabilities, and constraints, then infers which taxonomy sections each serves) is more resilient and doesn't require cross-skill coordination.

---

Quality Checks

Before reporting any phase (or the pipeline) complete, verify:

• Every phase output exists at its declared path under .claude/deliverables/campaigns/<slug>/ with valid frontmatter
• Preconditions were checked before each phase ran (hard: company-identity confidence >= 3; per-phase input file exists)
• Prior work detection asked before any overwrite; nothing was silently overwritten
• Every claim, proof point, and differentiator in the copy traces to the brief or a loaded context file; nothing invented
• Stage isolation held: the Design agent read only copy.md plus the section catalog / brand design files, never context files or the brief
• Section selection and ordering satisfy the section-taxonomy constraints (no duplicate section types, ordering rules respected)
• CTA copy, form fields, and page structure follow modules/conversion-playbook.md rules or the deviation is flagged in the QA report
• QA report scores all 10 lp-audit-taxonomy dimensions and lists every flagged issue with location
• Gaps, soft-dependency degradations, and human inputs used are listed in the completion summary