technical-documentation

Patterns for README, API spec, design doc, and user guide writing, and for auditing existing docs against the code they describe. Documentation rots in two directions: it over-claims capabilities that were never built or were removed, and it under-claims by still calling shipped work "planned." Teams reliably audit only the first direction, so the second accumulates unchecked; the audit pattern below exists to catch both. Not every rationale belongs in a document: a rationale belongs wherever the reader who needs it will be standing: a conventions file, a design doc, or a comment at the line itself.

Document types

Match structure and depth to audience: developers get technical depth, team members get context plus depth, end users get no jargon and step-by-step instructions.