documentation-strategy

# Documentation Strategy Decide what gets documented, where, by whom, and how it stays fresh. Stack-agnostic. Applies to internal team docs, product docs, runbooks, READMEs, and knowledge bases. --- ## When to use - Setting up documentation for a new team or product - Auditing existing documentation - Fixing stale or scattered docs - Choosing a documentation tool or platform - Defining what gets documented and what doesn't - Establishing maintenance cadence - Scoping technical writing work - Designing onboarding documentation (use alongside `team-onboarding-playbook`) ## When NOT to use - Writing the actual content of a single document (use `content-and-copy`) - Customer-facing knowledge base copy (use `content-strategy`) - Code comments and inline documentation (covered by `code-review-web`) - One-off blog posts or articles (use `content-and-copy`) --- ## Required inputs - The audience (internal, external, customer, dev, exec) - Existing docs and their state (where, what shape, last updated) - Team size and growth trajectory - The kinds of work that produce documentation (engineering, product, ops, support) - Tools currently in use --- ## The framework: 4 categories of documentation Different categories of doc serve different purposes. Conflating them is how docs get bad. ### Category 1: Reference What things are. Looked up when needed. Examples: API reference, configuration options, glossary, architecture diagrams, contact lists, decision log entries. Proper...