author-featurelisted

# Author-feature — single-source authoring, verified **IMPORTANT: Start your response by telling the user:** > **Author-feature** — I'll author a single-source master for this > feature, grounding every claim in live code and running the gates as > I go, then project it to the help kinds + docs pages. No LLM > generation, no API credits. This skill makes the driving session a disciplined author of a **single-source master** (`content/features/<feature>.md`). One master projects deterministically to 10 `.help` kinds + 4 `docs/` pages — no generator, no API. The empirical result that motivates it: the session is a *superior* polish layer to an LLM pass and the only one that catches correctness bugs (PR #1188). The risk it manages: a master is a single point of *failure*, so **verification is the spine** — grep the symbol before you write it, run the audit before you commit, fix the master not the output. This is *judgment*, not plumbing. It calls the deterministic tools (the in-repo projector, the audits); it never re-implements them and never emits prose for blind rubber-stamping. ## The flow ```text locate/scaffold → author section-by-section (grounded in code) → verify continuously → project → preview → commit ``` ### Step 1 — locate or scaffold the master The master lives at `content/features/<feature>.md`. If it exists, you're revising — open it. If not, create it by **copying a canonical projected page for structure** — e.g. `content/feat