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, ADRs, runbooks, tutorials, how-to guides, reference docs, module docs, requirements, acceptance criteria, user stories, or code comments. - 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 - 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 editing docs outside the user's request, ask whether docs are in scope unless a repo validator requires the update. 2. Living documentation has an owner, a nearby source of truth, and a change path; orphaned prose becomes misinformation. 3. One doc has one reader situation: tutorial, how-to, reference, expla