documentationlisted

# Documentation ## Iron Law `DOCUMENT ONLY WHAT NEEDS PROSE. KEEP DOCS NEAR THE CODE, CONTRACT, OR TEAM THAT MAINTAINS THEM.` ## When to Use - The user asks for or approves READMEs, runbooks, tutorials, how-to guides, reference docs, module docs, or code comments describing code as it exists. - Authoring or revising Consult SKILL.md files; skills are documentation for agents and follow the same rules. ## When NOT to Use - Forward-looking documents: design docs, ADRs, RFCs, tech specs, PRDs, requirements, strategy. Consult does not cover these; use a dedicated writing skill such as [Terse](https://github.com/kreek/terse). - Ordinary implementation where docs were not requested, approved, or required by a validator. Name the possible gap in the final response instead of editing docs. - CHANGELOG, release notes, migration notes, version manifests; use `release`. API contract shape; use `api`. ## Rules 1. Documentation is a separate work product, not an implementation reflex. Run only when requested, approved after a concrete gap is found, or required by validation. 2. Check whether the answer already lives in code, schema, tests, CLI help, OpenAPI, or a dashboard. Write only the missing context and link the source of truth; do not restate generated facts. 3. Encode the rule in names, types, schemas, or tests first. Add a comment only for the why that remains non-obvious. 4. One doc, one reader situation (tutorial, how-to, reference, explanati