| name | docs |
| description | Write documentation โ user-facing, technical, runbooks, onboarding, changelogs. Less is more: only document what code can't tell you. |
| user-invocable | true |
Documentation
Less is more. Agents and humans can gather context on the fly. Only document what's hard to see from code:
- Architecture โ Component relationships, data flow, system boundaries
- Why โ Decisions, constraints, tradeoffs (not what)
- Operations โ Procedures that require specific steps
- User interfaces โ Public APIs, CLIs, tools
Routing Table
| Task | Subskill | When to Use |
|---|
| User-facing (CLI, API, tools) | write-user.md | Public interfaces, README, guides |
| Internal technical | write-technical.md | Architecture docs, system design |
| Runbooks | write-runbook.md | Operational procedures, troubleshooting |
| Onboarding | write-onboarding.md | New contributor guide |
| Changelogs | write-changelog.md | Release notes |
Core Principles
1. Don't document what code tells you.
If someone can read the function and understand it, don't write docs. Comments rot. Code is truth.
2. Architecture over implementation.
Document component boundaries, data flow, integration points. Not how functions work internally.
3. High-level, like a principal engineer.
Write for someone who understands systems but doesn't know THIS system. Skip basics.
4. Diagrams over prose.
One ASCII diagram or mermaid chart replaces paragraphs. Show structure visually.
5. Reference the code, don't duplicate it.
See harness/agent/execution.go:306-500 beats copying code into docs.
Decision Tree
Need documentation?
โโโ Public interface (CLI, API)? โ write-user.md
โโโ System architecture? โ write-technical.md
โโโ Operational procedure? โ write-runbook.md
โโโ New contributor setup? โ write-onboarding.md
โโโ Release notes? โ write-changelog.md
โโโ Implementation details? โ DON'T DOCUMENT. Code is the doc.