---
name: repo-to-landing
description: Turn a technical repo into landing-page copy, with every claim cited to the code that proves it.
disable-model-invocation: true
---

# Repo to landing

Produce landing-page copy for the current repository where **every claim carries a citation** to the file that evidences it. The citation rule is the whole skill: capabilities the code can't evidence do not go on the page, however good they'd sound. That's what makes the output trustworthy enough to ship.

Use the vocabulary and channel shapes from the marketing-content skill; write under the anti-slop skill.

## Step 1: evidence sweep

Explore the repo and build the **proof inventory**: a list of what this thing verifiably does, one line each, with a `path:line` (or file) citation per capability.

Look in order at: README and docs/, the package manifest (name, description, bin, exports), CLI help output or command definitions, public API surface, examples/ and tests (test names are honest feature lists), recent releases or CHANGELOG. Note concrete numbers wherever they exist (benchmarks in the repo, defaults, limits, supported platforms/versions): numbers are rung-2 proof.

Completion criterion: an inventory where every entry has a citation, plus a short "claimed but unevidenced" list for anything the README asserts that the code doesn't show. That second list goes to the user, never to the page.

## Step 2: positioning check

- If `CONTENT.md` exists at the repo root, use its reader, promise, and objections; reconcile its proof inventory with Step 1's citations.
- If it doesn't, run a short grilling round: at most 7 questions, one at a time, each led by your recommended answer. Reader, promise, why-now vs the incumbent, top two objections, CTA reality (is there a hosted thing to sign up for, a package to install, a repo to star?), tone in one line.
- If the answers reveal genuinely unsettled positioning (the user hesitates on reader or promise), stop and recommend a full grill-me-content session instead of guessing.

Write what was decided into `CONTENT.md` (create or update) so the next run skips this step.

## Step 3: draft the page

Build the landing skeleton from the marketing-content skill:

- **Hero**: hook + promise + one CTA. The subtitle carries the promise plainly; the title can take the risk.
- **Pillars** (2-4): each pillar is one claim from the proof inventory plus its proof, shown at the highest rung available (a code snippet, a real number, a terminal capture description). Pillar order follows the reader's questions, not the architecture.
- **How it works**: 3-5 plain steps, each one traceable to the code (cite the entry point or command).
- **Objections**: answered inline where they occur, in the pillar or step that raises them.
- **Closing CTA**: the same single CTA, restated once.

Emit the draft as Markdown with an explicit slot map (`hero.title`, `hero.subtitle`, `hero.cta`, `pillar[1].claim`, `pillar[1].proof`, `how[1]`, `closing.cta`) so it drops into any framework. Each slot line ends with its citation in a comment. When the user points at existing page files, write into those instead, preserving their component structure.

## Step 4: audit and hand over

1. **Citation audit**: walk every claim on the page back to its inventory entry. A claim without one gets cut, no exceptions.
2. **Anti-slop pass**: run the anti-slop skill's full self-review on the copy.
3. Hand over: the slot-mapped draft, the "claimed but unevidenced" list from Step 1 (as candidate proof to go create), and the one-line note of which CTA metric this page should move.

Completion criterion: every slot filled, every claim cited, both audits passed.

---

*This is the manual version. [Reactor](https://reactor.tools) runs it automatically against your saved brand voice, Guard rules, and performance data.*