Apply the Diataxis framework: identify which of the four documentation kinds you're writing (tutorial/how-to/reference/explanation), keep them separate, and organize the whole docs set around the reader's journey rather than the system's structure.
How this skill is triggered — by the user, by Claude, or both
Slash command
/technical-writing-docs:diataxis-documentationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
| Kind | Serves | Oriented to |
| Kind | Serves | Oriented to |
|---|---|---|
| Tutorial | learning | the newcomer, hand-held |
| How-to guide | a task | the practitioner with a goal |
| Reference | information | the one who needs facts |
| Explanation | understanding | the one asking 'why' |
Most bad docs blur all four. Separating them is the biggest single improvement.
Map audiences + journeys (newcomer / integrator / operator); structure around what they're doing, not your module tree.
npx claudepluginhub mcorbett51090/ravenclaude --plugin technical-writing-docsGuides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.