diataxis
npx skills add https://github.com/cachemoney/agent-toolkit --skill diataxis
Agent 安装分布
Skill 文档
Diátaxis Documentation Framework
Apply the Diátaxis systematic framework to structure and write documentation.
The Four Documentation Types
Diátaxis identifies exactly four types, defined by two axes:
| Acquisition (study) | Application (work) | |
|---|---|---|
| Action (doing) | Tutorial | How-to guide |
| Cognition (thinking) | Explanation | Reference |
1. Tutorials â learning-oriented
Write tutorials as lessons. Take the learner by the hand through a practical experience where they acquire skills by doing.
- Use first-person plural (“We will…”)
- Show where they’re going up front
- Deliver visible results early and often
- Ruthlessly minimize explanation â link to it instead
- Focus on the concrete, ignore options and alternatives
- Aspire to perfect reliability
Load references/tutorials.md for full guidance.
2. How-to guides â goal-oriented
Write how-to guides as practical directions for an already-competent user to achieve a specific real-world goal.
- Name clearly: “How to [achieve X]”
- Use conditional imperatives (“If you want x, do y”)
- Assume competence â don’t teach
- Omit the unnecessary; practical usability > completeness
- Allow flexibility with alternatives
Load references/how-to-guides.md for full guidance.
3. Reference â information-oriented
Write reference as technical description of the machinery. Keep it austere, authoritative, consulted not read.
- Describe and only describe â neutral tone
- Adopt standard, consistent patterns
- Mirror the structure of the product
- Provide examples to illustrate, not explain
Load references/reference.md for full guidance.
4. Explanation â understanding-oriented
Write explanation as discursive treatment that deepens understanding. Answer “Can you tell me about…?”
- Make connections to related topics
- Provide context: why things are so
- Talk about the subject (title: “About X”)
- Admit opinion and perspective
- Keep closely bounded â don’t absorb other types
Load references/explanation.md for full guidance.
The Compass â When In Doubt
Ask two questions to classify content:
- Action or cognition? Is this about doing, or thinking?
- Acquisition or application? Is this for learning, or for working?
The intersection tells you which type you’re writing. Load references/compass.md for detailed decision guidance.
How To Apply
- Classify the content â use the compass questions above.
- Check for type mixing â does this piece try to do two things at once?
- Separate mixed content â pull explanation out of tutorials, pull instructions out of reference.
- Apply the type’s principles â follow the bullet points for that type above.
- Link between types â don’t embed, cross-reference instead.
Do NOT create empty four-section structures and try to fill them. Let structure emerge from content.
Example
User asks: “Write a getting-started guide for our CLI tool.”
- Classify: “Getting started” = the user is learning, by doing â Tutorial.
- Check: Not a how-to guide â the user isn’t solving a specific problem, they’re acquiring familiarity.
- Apply tutorial principles:
- Open with what they’ll build: “In this tutorial, we will install the CLI and deploy a sample app.”
- Lead through concrete steps with visible results at each stage.
- Minimize explanation: “We use
--verbosefor more output” not a paragraph on logging levels. - Link to reference for flag details, link to explanation for architecture.
- Result: A focused lesson, not a feature tour disguised as a tutorial.
Common Mistakes
| Mistake | Why it fails | Fix |
|---|---|---|
| Tutorial that explains everything | Explanation breaks the learning flow â learner loses focus | Move explanation to a separate doc, link to it |
| How-to guide that teaches basics | Competent users don’t need onboarding â it wastes their time | Assume competence, or split into tutorial + how-to |
| Reference with opinions and advice | Users consulting reference need facts, not guidance | Move advice to explanation |
| Explanation mixed into reference | Dilutes both â reference becomes verbose, explanation can’t develop | Separate into distinct documents |
| “Getting started” that’s actually a feature tour | No learning goal, no coherent journey â user doesn’t acquire skill | Pick one thing the user will accomplish, build toward it |
| Creating empty Tutorials/How-to/Reference/Explanation sections | Structure without content is useless scaffolding | Write content first, let structure emerge |
Critical Rules
- Never mix types. Each type has its own purpose, tone, and form.
- The user’s mode matters. Study vs. work is the fundamental distinction. Tutorials and explanation serve study. How-to guides and reference serve work.
- Link between types rather than embedding one inside another.
Deep Dives
Load reference files on demand for detailed guidance:
| Topic | File |
|---|---|
| Writing tutorials | references/tutorials.md |
| Writing how-to guides | references/how-to-guides.md |
| Writing reference docs | references/reference.md |
| Writing explanation | references/explanation.md |
| The compass decision tool | references/compass.md |
| Tutorials vs how-to distinction | references/tutorials-how-to.md |
| Reference vs explanation distinction | references/reference-explanation.md |
| Workflow methodology | references/how-to-use-diataxis.md |
| Why Diátaxis works (foundations) | references/foundations.md |
| The two-dimensional map | references/map.md |
| Quality in documentation | references/quality.md |
| Complex hierarchies | references/complex-hierarchies.md |