Documentation Strategy
Design and run a documentation system for a team or product.
Install
npx skills add rampstackco/claude-skills --skill documentation-strategy -g -a claude-code -y- Repository
- rampstackco/claude-skills1k
- Category
- Design
- Updated
- 9d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Design and run a documentation system for a team or product. Use this skill when planning what to document, choosing a documentation tool, organizing existing docs, fixing stale documentation, designing a maintenance cadence, or scoping technical writing work. Triggers on documentation, docs, tech writing, knowledge base, wiki, runbook, README, internal docs, doc audit, doc maintenance, stale docs, where do we document. Also triggers when the team is repeatedly answering the same questions or when onboarding takes too long.
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.
Properties:
- Comprehensive
- Fact-checked, kept accurate
- Searchable
- Stable structure (links don't break)
- Version-aware where relevant
Category 2: How-to
How to do specific tasks. Procedural.
Examples: "Deploy to staging," "Reset a password," "Onboard a new contractor," "Run the backup restore drill."
Properties:
- Step-by-step
- Tested by someone who didn't write it
- Includes the prerequisites
- Includes troubleshooting
- Versioned to the system it documents
