docs-as-deliverablelisted

# Docs as a First-Class, Diagrammed, Tested Deliverable Documentation is a deliverable, not exhaust. Hold it to the same bar as the code: tight present-tense prose, diagrams expressed as code, every signature and flag verified against the implementation, and comprehension proven by readers — not assumed. ## When to use Apply whenever you ship code, hand a project to another team, write or revise a README/ARCHITECTURE/runbook, or change behavior that an existing doc describes. Documentation work belongs in the same change as the code it documents — not a follow-up "docs pass" that never comes. Red-flag thoughts that mean STOP and apply this skill: - "I'll update the docs later / in a separate PR." - "The diagram is close enough — the code only moved a little." - "This describes how it *should* work" (instead of how it does). - "Everyone on the team already knows this, so I don't need to spell it out." - "I'll keep the old design doc around as-is; people will figure out it's outdated." - "I'll hand-type the config table into the docs so it reads nicely." - "The doc's example commands are close enough — nobody runs them literally." ## The rule 1. **Write to a reader, in present tense, about what is.** Describe the system as it actually behaves now. Cross-link instead of repeating; one authoritative statement per fact. Cut hedging and filler. 2. **Verify every concrete claim against the source.** Open the code/config and confirm each function signature, CLI flag, endpoint