Write documentation with the framework's gates

What it produces

One document — a README, a wiki page, product documentation, API docs or a technical post — written against the framework's single standard and verified against the tree: every named file exists, nothing restates what the environment already says, and each section ends on a checkable completion criterion. A document that cannot be verified exits not-covered: <reason>.

Steps

1. Read the voice: references/voice.md. The reply to the person, and the opening of the document, follow it. Then read the writing standard: references/documentation-writer.md. If either file is missing, stop and say INCOMPLETE: writing standard absent. Then read the reference for the artifact at hand: references/readme-writer.md for a README, references/contributing-writer.md for CONTRIBUTING, a code of conduct or a release flow, and references/security-md-writer.md for SECURITY.md.
2. Read the tree the document is about. Not from memory, not --help. The README names commands that exist. The API doc names endpoints in the code. The wiki names directories on disk. Every claim traces to a file or a command.
3. Write and keep it a document, not a cache. Never restate the environment (config, CLI output, directory layout). Never repeat the spec or the ADR it points at. One idea per sentence. One meaning per word. Every section ends on a checkable criterion ("the command in section 2 runs", never "the reader understands").
4. Verify before done. Walk every named file and command. A missing file or a command that does not run is a finding against the document. A passage that could not be verified exits not-covered: <reason>. Never invent to make a section pass.
5. Write only into the homes the user named (README.md, docs/, a wiki dir). The change lands through the normal review. This skill never approves its own document.

What this is not

Not the changelog; not a feature plan (/ai-orchestrator); not a finding (/ai-note); not an issue or incident report (/ai-issue-report). And it is not a licence to repeat the environment: a document that restates --help or the config is a cache, and a cache earns its load only when the lookup is expensive.

• "The reader will understand it from context" — a completion criterion is not a feeling: if a section cannot be checked against a file or a command, it gets a not-covered reason, and a doc that claims to be verified when it is not is the false-green this framework exists to stop.

Done when

Every named file exists and every named command runs, no passage restates the environment, every section ends on a checkable criterion, anything unverifiable carries a not-covered: <reason> exit, and the user's named home was the only place written. The doc is a claim; the tree is the evidence.

The ai-engineering seam

1. Two files, two jobs. references/voice.md is how a reply or a handoff is shaped. references/documentation-writer.md is the prose standard for every surface that writes for humans: incident reports (/ai-issue-report), AGENTS.md authoring (/ai-agents-md), and any README the framework installs. Voice does not relax a checkable completion criterion.
2. ai-write never writes into .ai-engineering/ — governance artifacts are not product docs. Its home is the tree the user names: README.md, docs/, a wiki directory.
3. The verdict on whether a draft is good belongs to the decide tier; the mechanical checks (every named file exists, every named command runs) belong to verify (.ai-engineering/config.toml pin).

Lifecycle

Lane: standard, full Trigger: public-interface Trigger kind: judgment Trigger when: the diff changes a public interface, a documented behaviour or a command a README shows Writes: README.md, docs/ Read by: humans and the surfaces Dies: when the code it documents dies Next: none