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 writing/reviewing READMEs, runbooks, tutorials, how-to guides, reference docs, module docs, or code comments: documentation that describes code and systems as they exist. - Authoring or revising Consult SKILL.md files; skills are documentation for agents and follow the same clarity rules. - Deciding whether prose is needed or whether a type, schema, generated reference, test, or command output should be the source of truth. ## When NOT to Use - Forward-looking documents that record decisions or propose futures: design docs, ADRs, RFCs, tech specs, PRDs, requirements, acceptance criteria, system analyses, strategy. Consult does not cover these; use a dedicated writing skill if one is installed, such as [Terse](https://github.com/kreek/terse). - Ordinary implementation where docs might later be useful but were not requested, approved, or required by a validator. Name the possible docs gap in the final response instead of editing docs. - API contract design; use `api`. - Release coordination, changelog process, release notes, version manifests, or migration notes; use `release`. Those artifacts land only during release prep. - Alert mechanics and dashboards; use `observability`. ## Core Ideas 1. Documentation is a separate work product, not an implementation reflex. Before