---
name: doctrine-write
description: Use when the user asks for an important document written or rewritten with the doctrine: proposals, briefs, PRDs, handoffs, reports, or any prose deliverable that must be clear, accurate, and airtight.
---

# Doctrine Write

Prose as the deliverable, under the doctrine. Covers authoring from scratch and rewriting existing text; in rewrite mode the existing text enters as draft 1 with the author's meaning preserved — tighten the words, don't change the claims.

**REQUIRED BACKGROUND:** Read the `doctrine` skill first. The gate is the hub's full three parts; mapping onto its posture:

- **Native checks** (doctrine step 3) = **every check the project itself documents as a gate** for the place the doc lands — a prose or markdown linter (`vale`, `markdownlint`), a docs build, a link, spelling or frontmatter check, whatever its `CLAUDE.md`, README, review doc **or task runner** lists — **plus** the doctrine's docs-diff form: re-verify every claim you edited against its source, and run a link and path check over the result. Read `package.json` scripts or their equivalent yourself rather than trusting a summary: **a project with no build step still has gates**, and a doc whose gate came clean and then failed the repo's docs linter in CI was gated by nothing that mattered. Where the destination has no tooling around it, the docs-diff form is the whole of native checks — a complete answer, not a gap to keep hunting. **The review-lens wave is not native checks**: it is the designated review below, and collapsing the two leaves a two-part gate reported as the full three.
- **Designated review** = the review-lens wave in step 4, whose **clarity** lens runs the `writing-clearly-and-concisely` skill (Strunk's Elements of Style; in softaworks/agent-toolkit and elsewhere) if installed. **Resolve that skill before you dispatch anything**, because from inside a subagent prompt a bare filename resolves to nothing: locate the installed `elements-of-style.md` yourself — `writing-clearly-and-concisely/elements-of-style.md` under your host's skill directory, which the hub's host reference names, otherwise list your skills directories — and hand the lens the **absolute path** with an instruction to Read it. Pass the path, never the text: it runs to over 12,000 words, far past the point where pasting it crowds out the draft. Where the skill is not installed, hand that lens Strunk's core rules inline instead — omit needless words, active voice, definite concrete language, one idea per paragraph — and **say in the report which of the two it got**. A lens improvising Strunk from memory returns findings that look exactly like a real pass, and the slot it fills is the one the doctrine says must never go silently empty.
- The **red team** (doctrine step 4) reads the whole doc as a hostile reader, after the wave has passed it.

Boundaries: doctrine-docs owns codebase-doc sweeps; doctrine-research owns producing researched content. This wrapper is for when the writing itself is the deliverable; chain it after either.

## Flow

1. Ask the user what the request left open: **audience and what the reader should know or do afterward** — write that down verbatim as the doc's **anchor** (every review lens checks against it); register, format, length; source material; destination. For the highest-stakes docs, offer the **judge panel** here: 2–3 candidate drafts in different structures, judged, the winner carried into step 3. Off by default — it triples drafting cost. **If they take it, it runs after step 2 and not now**, because every part of it needs the ledger: one agent per structure, each handed the anchor, the ledger and the agreed register, format and length from step 1 — settled constraints an author without them drafts against a guess — and each writing a **whole draft in one voice** (never a section each), then a **fresh-context judge** — handed the anchor, the ledger and the drafts at neutral filenames, so it cannot rank them by author — grading on one question only: which structure gets *this* reader to the thing they must know or do, and what each loser does better. You then write the winner up in step 3, folding in what the judge salvaged. The panel is the **one** sanctioned parallel draft, and it is sanctioned because no delivered sentence ends up with two authors.
2. **Ground**: build a claim ledger from the source material — **every fact and number the doc may assert, each with its source line** (where it lives, who receives it, and how it is amended: **The anchor and the claim ledger** below — build both there before a word of step 3 is drafted). No web-sourced claims unless the user authorizes external sourcing. A gap becomes an explicit unknown in the doc, never a plausible guess.
3. **Draft in one voice** — written directly, not delegated section-wise: parallel agents drafting *sections* of one document produce Frankenstein prose. The doctrine's parallelism belongs in review, not drafting — **with step 1's judge panel as the one exception**, where each agent writes a whole draft and only one of them survives, so the rule it appears to break is the rule it actually keeps. Where the panel ran, what you write here is the winning draft plus whatever the judge salvaged from the losers, still written through in one voice. (Rewrite mode skips this step; the provided text is draft 1.)
4. **Review wave** — parallel independent lenses, none of them the author (the author self-reviewing preserves author blindness):
   - **Clarity**: Strunk rules via writing-clearly-and-concisely (or the fallback prompt); findings with line references.
   - **Accuracy**: every checkable claim against the ledger and sources; an unsourced claim is cut or moved to unknowns. In rewrite mode, unsourced claims in the user's own text are **returned as flagged rather than cut** — a lens has no user, so it names them in its findings and **you put them to the user on receipt**, recording each ruling in the ledger where the next loop's lenses will read it. The lens also diffs against the original for semantic drift — rewrites compress and clarify, never alter claims — which means **the original text must be handed to it**; it cannot diff against a file it was never given.
   - **Audience fit**: does each section serve the anchor? What would this specific reader skip, misread, or push back on?
   - **Structure**: BLUF first, one idea per paragraph, headings that earn their place, length within the agreed bound.
   Merge and dedupe findings; edit.
5. **Red team** (doctrine step 4): the red team reads the doc as the hostile reader — where it got confused, misled, or bored, plus the strongest case against the doc's conclusion. Verify each finding against the ledger before acting; adversarial reviewers produce false positives.
6. **Loop to doctrine step 5's gate for this phase**, its clean test and its alarms as written and none of them restated here, **under the hub's prose-deliverable exit, adopted here by name**: the deliverable is prose and every sentence of it is production-facing. This gate's three seats are native checks + lens wave + red team. What is specific to prose is what counts as blocking in a document: **a false or unsourced claim, a section that does not serve the anchor, a structural defect, semantic drift in a rewrite, a failed check.** Which bucket a finding lands in is doctrine step 5's three-bucket rule, unchanged here: a sentence that could be shorter and means the right thing is not a finding, and for a prose deliverable the bar is what the reader does next, never the polish of the wording. One of step 5's rules bites hardest in prose: simplification runs before the pass that certifies the doc (doctrine step 6), one pass that *deletes* redundancy and decoration rather than polishing it. Do **not** run it again after that pass. Prose is the medium where every pass finds something shorter, and a simplification landed after the certifying pass ships uncertified.
7. **Deliver**: write the doc to the destination agreed in step 1 (doctrine step 7: work is not done until it lands). That agreement is the authorization to **write** — do not ask for it again, and do not downgrade to "writing only if asked". **Committing follows the repository's delivery norm** — its CLAUDE.md, or the pattern in its history. Where the norm is to commit, commit as part of delivery rather than stopping to ask; where it is patch handoff, hand over the diff and say so. **An unrelated dirty file is not a reason to stop** — stage your own paths and commit those; only an actual conflict with someone else's in-flight work in the files you touched is. Agreeing a destination is not by itself agreement to a commit. In chat: the doc's one-line thrust plus anything needing the user's judgment.

## The anchor and the claim ledger

Two artifacts, one file, built in steps 1 and 2 **before a word is drafted** and handed to every lens, the red team, the judge panel if it runs, and any agent that touches the doc. The **anchor** is the user's own words for the audience and for what the reader should know or do afterward, plus any Done means items the phase serves (doctrine step 1). The **claim ledger** is the general form named in step 2: every fact and number with its source line, in enough detail that someone holding the ledger and not the sources can check the doc against it. A fact absent from the ledger is not the doc's to assert.

**It lives beside the destination agreed in step 1** — the doc's path with a `-ledger` suffix (`<doc>-ledger.md`) — or in the project's own location for working notes where it has one, or in **the scratchpad** (the session temp directory if there is one, else a temp directory outside every repo) where neither is writable or the user does not want working files in the repo. Name the path in the report either way, and ask at delivery whether it ships with the doc or is dropped. It is amended, never frozen: source material supplied later, anything the user ratifies, every flagged claim they rule on, every red-team finding you verified or refuted, and whatever doctrine step 5 puts in that section, under a trailing `## Run state (orchestrator only)` heading that no reviewer is handed, since a lens told the next blocking finding fires the round alarm has been told how badly the pass needs to be clean.

**Paste it into each prompt; do not point at it.** A lens pointed at a path reads its own summary of it (doctrine step 4). The **accuracy** lens exists to check the draft against the ledger and has no other fact base — handed a draft alone it reports that the claims look sourced, which is what an invented fact looks like, and the wrapper's only defence against invented facts then reports clean for four passes. The **audience-fit** lens grades sections against the anchor by name, so state the anchor in the prompt in the words step 1 recorded, with any Done means items it carries per doctrine step 1, rather than trusting the draft to carry it — and the agreed register beside it, which is the user's ruling on tone and sits outside the anchor by this file's definition. The **structure** lens gets the agreed bound, register and format from step 1's record — they are outside the anchor by that word's own definition here, and a lens told to judge "length within the agreed bound" holding no bound invents one. The **red team** gets both alongside the draft, per doctrine step 4. In rewrite mode the **original text** goes to the accuracy lens too, for the semantic-drift diff it is already required to run.

Not for quick edits or informal messages — a single clarity pass covers those.

## Red flags

- A lens dispatched with the draft and no ledger, reporting that the claims look sourced.
- The clarity lens working from remembered Strunk because nobody resolved the skill's path.
- A number in the doc that no line of the ledger accounts for.
- Every loop tightening one more sentence, and the phase never closing.
- A rewrite that improved a claim instead of the words carrying it.
- The doc landing in a repo whose docs linter nobody ran.
- The anchor and the counters living only in the conversation on loop 3.
- Sections drafted in parallel and stitched.