What problem does it solve?
Documentation has audiences. README for new users, API docs for integrators, architecture docs for maintainers, inline docs for contributors. Wrong audience = wrong documentation. Before writing, identify who will read it and what they need to accomplish.
Core Features & Use Cases
- Audience determines format. A README walks someone through getting started. An API reference lists every parameter with types. An architecture doc explains why decisions were made. Don't mix formats.
- Code is the source of truth. Never copy code into documentation — reference file paths instead. Copied snippets rot as soon as the source changes.
- Concise, specific, active voice. "Returns a list of users" not "A list of users is returned by this function." Cut filler words entirely.
- Show, don't tell. A working example communicates more than three paragraphs of explanation.
- Documentation Types: README, API Reference, Architecture, Inline Documentation, Changelog, Configuration.
Quick Start
Draft a documentation pattern set that covers the most common doc types (README, API reference, architecture) and cite the references as templates.