documentation-patterns

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.