documentation-strategy

1# Documentation Strategy
2 
3Decide 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.
4 
5---
6 
7## When to use
8 
9- Setting up documentation for a new team or product
10- Auditing existing documentation
11- Fixing stale or scattered docs
12- Choosing a documentation tool or platform
13- Defining what gets documented and what doesn't
14- Establishing maintenance cadence
15- Scoping technical writing work
16- Designing onboarding documentation (use alongside `team-onboarding-playbook`)
17 
18## When NOT to use
19 
20- Writing the actual content of a single document (use `content-and-copy`)
21- Customer-facing knowledge base copy (use `content-strategy`)
22- Code comments and inline documentation (covered by `code-review-web`)
23- One-off blog posts or articles (use `content-and-copy`)
24 
25---
26 
27## Required inputs
28 
29- The audience (internal, external, customer, dev, exec)
30- Existing docs and their state (where, what shape, last updated)
31- Team size and growth trajectory
32- The kinds of work that produce documentation (engineering, product, ops, support)
33- Tools currently in use
34 
35---
36 
37## The framework: 4 categories of documentation
38 
39Different categories of doc serve different purposes. Conflating them is how docs get bad.
40 
41### Category 1: Reference
42 
43What things are. Looked up when needed.
44 
45Examples: API reference, configuration options, glossary, architecture diagrams, contact lists, decision log entries.
46…