diataxis

Structure, classify, and write documentation using the Diátaxis framework. Use when writing docs, README files, guides, tutorials, how-to guides, API references, or organizing documentation architecture. Also use when asked to improve documentation, restructure docs, decide what type of doc to write, or classify existing content. Covers tutorials, how-to guides, reference, and explanation.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "diataxis" with this command: npx skills add cachemoney/agent-toolkit/cachemoney-agent-toolkit-diataxis

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)TutorialHow-to guide
Cognition (thinking)ExplanationReference

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:

  1. Action or cognition? Is this about doing, or thinking?
  2. 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

  1. Classify the content — use the compass questions above.
  2. Check for type mixing — does this piece try to do two things at once?
  3. Separate mixed content — pull explanation out of tutorials, pull instructions out of reference.
  4. Apply the type's principles — follow the bullet points for that type above.
  5. 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."

  1. Classify: "Getting started" = the user is learning, by doing → Tutorial.
  2. Check: Not a how-to guide — the user isn't solving a specific problem, they're acquiring familiarity.
  3. 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 --verbose for more output" not a paragraph on logging levels.
    • Link to reference for flag details, link to explanation for architecture.
  4. Result: A focused lesson, not a feature tour disguised as a tutorial.

Common Mistakes

MistakeWhy it failsFix
Tutorial that explains everythingExplanation breaks the learning flow — learner loses focusMove explanation to a separate doc, link to it
How-to guide that teaches basicsCompetent users don't need onboarding — it wastes their timeAssume competence, or split into tutorial + how-to
Reference with opinions and adviceUsers consulting reference need facts, not guidanceMove advice to explanation
Explanation mixed into referenceDilutes both — reference becomes verbose, explanation can't developSeparate into distinct documents
"Getting started" that's actually a feature tourNo learning goal, no coherent journey — user doesn't acquire skillPick one thing the user will accomplish, build toward it
Creating empty Tutorials/How-to/Reference/Explanation sectionsStructure without content is useless scaffoldingWrite 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:

TopicFile
Writing tutorialsreferences/tutorials.md
Writing how-to guidesreferences/how-to-guides.md
Writing reference docsreferences/reference.md
Writing explanationreferences/explanation.md
The compass decision toolreferences/compass.md
Tutorials vs how-to distinctionreferences/tutorials-how-to.md
Reference vs explanation distinctionreferences/reference-explanation.md
Workflow methodologyreferences/how-to-use-diataxis.md
Why Diátaxis works (foundations)references/foundations.md
The two-dimensional mapreferences/map.md
Quality in documentationreferences/quality.md
Complex hierarchiesreferences/complex-hierarchies.md

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Automation

coolify-compose

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

perplexity

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

backend-to-frontend-handoff-docs

No summary provided by upstream source.

Repository SourceNeeds Review