/landing-page-generator

name: landing-page-generator
description: "Write landing pages (PAS, AIDA, StoryBrand) from a brief or README, as HTML with privacy, terms, changelog, setup pages. Use for sales copy, hero sections, CTAs, README rewrites. Don't use for blogs, release notes, project docs, or coding mockups."
license: MIT
effort: high
dependencies:
  - frontend-design
metadata:
  version: 1.7.0
  author: "Luong NGUYEN <luongnv89@gmail.com>"

Landing Page Generator

Generate landing pages using proven copywriting frameworks (PAS, AIDA, StoryBrand). One skill, two modes: write conversion-focused marketing copy from a product brief, or transform an existing project README into a scannable, visual landing page. A full landing page ships with the companion pages its footer links to: Privacy Policy, Terms of Use, Changelog, and Docs, each where it applies. The last step builds the landing page and those pages as HTML with `frontend-design`.

Two Modes

Pick the mode that matches the input and deliverable:

| Mode | Use when | Input | Output | Where | |---|---|---|---|---| | **A — Landing copy** | You need marketing copy for a sales/landing page | Product/service brief | Conversion-focused copy (hero → CTA) + A/B notes + companion page copy, in chat; the built pages in `landing-page/` | This file, below | | **B — README landing page** | You have an existing project `README.md` to make persuasive and scannable | Repo `README.md` + project files | Rewritten `README.md` (mermaid, tables, collapsed details) + `README.backup.md` + companion page files + the built pages in `landing-page/` | `references/readme-mode.md` |

If the user asks to "turn my README into a landing page", "make my GitHub page sell the project", or similar, follow **Mode B** in `references/readme-mode.md`. Otherwise use **Mode A** below. When unsure which applies, ask.

Companion Pages

Decide each companion page from facts the brief or the project states, never from a guess. Record each decision with its reason:

| Page | Applies when | |---|---| | Privacy Policy | Always | | Terms of Use | The product has user accounts, a paid plan, a free trial, or a subscription. An open-source tool with none of these gets no Terms page: its license governs use | | Changelog | Always. Mode B links an existing history file instead of writing one | | Docs | The product is a CLI, library/SDK, self-hosted service, plugin/extension, or API, or the brief or project names a setup step the product's users perform outside its UI (install command, API key, environment variable, config file, DNS record). Contributor setup does not count |

• If the user asks for a single section or says "landing page only", skip every companion page and record the skip.
• If the user names extra pages, add them to the pages the table applies. If the user says "only" those pages, write only them and record the rest as `skipped — not requested`.
• If the user asks for one companion page alone, write only that page and name the footer link it needs. Mode A runs Step 6 for it and asks only for a missing product name; a repo file follows `references/readme-mode.md` → *Edge Cases*.

Mode A delivers each page as a copy block in chat. Mode B writes `PRIVACY.md`, `TERMS.md`, `CHANGELOG.md`, and `docs/getting-started.md`, and never overwrites an existing file. Sources, templates, and checks: `references/companion-pages.md`.

Anti-Slop Rules

AI-generated marketing copy has predictable tells that kill credibility. See `references/anti-slop-rules.md` for banned phrases and structural patterns to avoid.

**Quick test:** read each sentence and ask "does this give the reader information they didn't already have?" If not, cut it.

Default Quality Bar

In both modes, the final deliverable (Mode A copy and its structure; Mode B README layout; the companion pages; the built pages) must be professional, production-ready, elegant, and premium, even when the user never asks. The brief or project voice decides the tone; this bar decides the finish:

• **Professional**: precise and credible; no hype
• **Production-ready**: ship-ready, every section complete; the only allowed gaps are labeled `[proof needed]` (Mode A) or `[placeholder]` (Mode B) markers
• **Elegant**: concise, one consistent voice, clean scannable hierarchy
• **Premium**: confident restraint, specific claims, polished formatting

These are qualities of the output, never words to put in it: do not write "premium", "elegant", or "world-class" into the copy.

Prerequisites

Before writing, confirm the user supplied enough detail to make specific claims:

• Product/service name and target audience
• Problem solved and primary desired action
• Proof points, metrics, testimonials, or named differentiators
• Pricing/trial/guarantee details if a pricing section is requested

If proof is missing, write placeholders clearly labeled `[proof needed]`; never invent customers, metrics, guarantees, scarcity, compliance claims, or commands.

Dependency Preflight (mandatory)

This skill optionally invokes `frontend-design`, declared in frontmatter `dependencies`, for the page build only (Mode A Step 7, Mode B Step 8). Before the first write:

command -v asm >/dev/null || echo "asm not installed: npm install -g agent-skill-manager"
asm deps discover "<this skill's directory>" --json
printf 'lp_session=%s\n' "landing-page-generator-$(date +%s)-$$"   # record it; reuse it verbatim

When the page build is reached, run `asm deps acquire frontend-design --session <lp_session> --json` and read the returned `skillMdPath`. If `asm` is missing or the acquire fails, read `~/.claude/skills/frontend-design/SKILL.md` or `~/.agents/skills/frontend-design/SKILL.md`. Do not acquire it when the build is skipped (`references/page-build.md` → *Build decision*). If an acquire ran, run `asm deps release --session <lp_session> --json` at the end, including an early stop. Without `frontend-design`, the run falls back to copy only and records `page