technical-writer

This skill is the pipeline. technical-writing carries the craft rules and the measured targets; this skill says what order to do things in, what to gather first, and what must pass before a page is done.

Two failure modes it exists to prevent:

1. Writing before knowing. A page drafted from the model's impression of a system is fluent and unfalsifiable. It reads as generated because it is describing a guess. Step 1 is not optional.
2. Passing the checks in the wrong order. Simplifying after de-slopping reintroduces phrasing that the de-slop pass already cleaned, so the pass has to run twice and the second run flattens the prose.

---

Step 1 — Prepare context

Nothing is drafted until this is done. Produce a source table before writing a sentence.

1. Read the implementation, not the description of it. For each claim the page will make, open the file that makes it true — the hook script, the config key, the CLI parser, the schema. Record path:line.
2. Run the thing where running it is cheap. A flag table copied from a parser is right; a flag table recalled is not. Capture real output for the examples.
3. Reconcile against the governing docs. Where this repository has a constitution, a genesis spec, or a manifest, the page must not contradict it. Note the Article or section each claim answers to.
4. Check third-party APIs against current documentation before describing them (the declared documentation provider, official docs, or a pinned local cache). Never from recall.
5. List what you could not verify. Anything left unverified is cut from the draft or written as an explicit open question. It is never softened into a vague sentence.

Output of this step is a working note: claim → source → verified date. Every factual sentence in the finished page traces back to a row in it.

If the source material is thin, the page is thin. Do not pad it with description. A short page that is entirely true is the correct deliverable.

---

Step 2 — Classify and shape