# Documentation Strategy

Design and run a documentation system for a team or product.

- Repository: https://github.com/rampstackco/claude-skills (1014 stars)
- Category: Design
- License: MIT
- Last updated: 2026-10-27
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add rampstackco/claude-skills --skill documentation-strategy -g -a claude-code -y`
Codex: `npx skills add rampstackco/claude-skills --skill documentation-strategy -g -a codex -y`
Cursor: `npx skills add rampstackco/claude-skills --skill documentation-strategy -g -a cursor -y`
Gemini CLI: `npx skills add rampstackco/claude-skills --skill documentation-strategy -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add rampstackco/claude-skills`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/rampstackco/claude-skills/blob/HEAD/dist/codex/.agents/skills/documentation-strategy/SKILL.md