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 the sources do not refute, and correct a claim they refute.

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, and the red team in step 5, the absolute path with an instruction to Read it, so the red team holds the same method the lens grades by. Pass the path, never the text, to either seat: 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 and the red team 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 they 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. Record a length bound in exactly one unit, the unit the user's instruction names or words where it names none, and never a second unit beside it. Record every length you measure, the original's and each draft's, beside the exact command that produced it (wc -w <file> for words), so rerunning that command on the same text gives the same count. 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, the agreed register, format and length from step 1, 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 the source material behind it; 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 — while a claim the sources refute, meaning a source line states the contrary, is corrected to what that line says, with the correction recorded in the ledger beside that line and named to the user at delivery. Every claim in the user's own text that you put to the user, whether a lens returned it or you found it grounding the ledger, goes through doctrine step 1's direction test as you put it, with the result recorded in the ledger beside the question, and the ruling is recorded there when it comes, 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 the sources do not refute — 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 and the source material behind it 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 claim the sources do not refute, changed or dropped), 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 claim corrected because the sources refute it, 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). Beside the anchor and the ledger, each seat gets what it grades against:

• Every lens, clarity, accuracy, audience fit and structure, and the red team get step 6's list of what blocks in a document, pasted beside the blocking definition doctrine step 4 hands every reviewer seat: a seat holding only the general definition does not know that semantic drift in a claim the sources do not refute, or a section that does not serve the anchor, blocks here.
• The accuracy lens and the red team get the source material the ledger was built from, pasted, or under doctrine step 4's rule for an artifact too large for a prompt. The accuracy lens checks the draft against the ledger and each ledger line against the source it cites: handed a draft alone it reports that the claims look sourced, which is what an invented fact looks like, and handed the ledger alone it cannot catch a ledger line that misstates its source. These are the sources steps 1 and 2 gathered, never a licence for the external sourcing step 2 bars.
• 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.
• The audience-fit lens, the structure lens and the red team get the agreed register, length bound and format from step 1's record. They are the user's rulings and sit outside the anchor by this file's definition, and a seat told to judge "length within the agreed bound" holding no bound invents one.
• The red team also gets the clarity method resolved under Designated review above.
• In rewrite mode the original text goes to the accuracy lens, for the semantic-drift diff it is already required to run over every claim the sources do not refute, and to the red team, so it can attack a claim the sources do not refute that drifts in meaning or is dropped from both the draft and the ledger.

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 the sources do not refute 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.