---

name: diataxis description: Use whenever writing, editing, restructuring, or reviewing technical documentation — READMEs, API docs, guides, tutorials, reference, onboarding, or developer docs of any kind — to apply the Diátaxis framework, which splits content into four modes (tutorials, how-to guides, reference, explanation) that each serve a distinct user need. Trigger even when the user just says "write docs", "document this", "improve the README", or "our docs are confusing" without naming Diátaxis or documentation types. Use it to decide WHAT KIND of doc to write (via the compass), to diagnose docs that feel bloated, mix instruction with reference, or leave users unable to get started or find facts, and to improve docs in small safe iterations. Especially when you are unsure whether something belongs in a tutorial vs how-to vs reference vs explanation, or when one page is trying to do all four at once.

Diátaxis

A runbook for producing and fixing technical documentation with the Diátaxis framework. Diátaxis splits documentation into four modes — tutorials, how-to guides, reference, explanation — because they answer four different user needs that pull in opposite directions. The single idea that makes it work:

Most documentation problems are a single thing: content that tries to serve more than one need at once. Separate the four modes and most confusion dissolves.

Diátaxis is descriptive, not prescriptive — a way to understand documentation, not a template to fill in. Don't wait to understand the whole framework before applying it: pick one small thing, classify it, improve it, publish, repeat.

When to Apply

Use this skill when:

• Writing or generating new documentation of any kind (README, API docs, guide, onboarding, developer docs) — decide which mode(s) the content needs before writing it.
• A page is confusing, bloated, or "tries to do everything" — diagnose the type-mixing and split it.
• Users can't get started, can't complete a task, can't find a fact, or don't understand why — locate the missing or weak mode.
• Restructuring or auditing an existing doc set — apply the small-step workflow instead of a big rewrite.
• You're unsure whether something is a tutorial, how-to, reference, or explanation — run the compass.

Do not reach for this skill for pure prose/copy-editing within an already-correct mode (use a copywriting skill), or for design/spec/proposal documents — those are mostly explanation and are better served by dev-rfc or feature-spec.

The four modes

Each mode serves a different user, in a different situation, with a different content style. The quickest way to keep them straight:

Mode	Serves	Oriented to	Analogy	Answers
Tutorial	a beginner learning	learning, study	teaching a child to cook	"teach me, by doing"
How-to guide	a user working	a goal, a task	a recipe in a cookbook	"how do I achieve X?"
Reference	a user working	information	an encyclopaedia entry	"what is X exactly?"
Explanation	a user studying	understanding	an article about cooking	"why is X this way?"

Two of them serve practical steps (tutorial, how-to); two serve theoretical knowledge (reference, explanation). Two serve someone acquiring skill / studying (tutorial, explanation); two serve someone applying skill / working (how-to, reference).

The compass — decide what you are writing

When you are unsure which mode a piece of content belongs to, answer two questions. This is the master decision tool; the full tree is in compass-tree.md.

1. Does it inform action or cognition? — practical steps (doing) vs theoretical knowledge (thinking). 2. Does it serve acquisition or application? — study (learning) vs work (applying what you know).

	Action (practical steps)	Cognition (theoretical knowledge)
Acquisition (study / learning)	Tutorial	Explanation
Application (work / doing)	How-to guide	Reference

Read as a decision: informs action + serves acquisition → tutorial; informs action + serves application → how-to guide; informs cognition + serves application → reference; informs cognition + serves acquisition → explanation. Apply the compass at any scale — a whole document, a section, or a single sentence that has drifted into the wrong mode.

Common Symptoms

Start here. Match the situation, open its tree. Severity reflects how badly the reader is failed right now (see symptoms.md).

Symptom / trigger	Likely problem	Tree
"Write docs for X" / "document this" — and it's unclear what kind of doc	No mode chosen yet — classify first	compass-tree
A page feels bloated, rambling, or mixes teaching + steps + specs + opinion	Type-mixing — two needs in one document	wrong-type-tree
Beginners can't get started · competent users can't finish a task · people can't find a fact · users don't understand why	A missing or weak quadrant	gaps-tree
"Our docs are a sprawling mess — where do I even start?"	Needs the iterative workflow, not a rewrite	restructure-tree

How to use

1. Match the symptom in the table above and open its tree in references/. For a large existing corpus, run bash references/queries/scan-docs.sh <docs_root> first — it triages which pages show signals of more than one mode, so you know where to point the compass.
2. Classify with the compass — decide which of the four modes the content serves. When in doubt, open compass-tree.md.
3. Read the matching type guide — tutorials, how-to-guides, reference, or explanation — for how to write that mode well, and what to keep out of it.
4. Work in small steps. Follow workflow.md: choose something small → assess it → decide one next action → do it and publish. Never tear everything down to restructure top-down.
5. Assess against quality. Use quality.md to judge functional quality (accuracy, completeness, consistency) and deep quality (does it feel good to use, anticipate the user's needs).
6. Record an audit with assets/templates/report.md when reviewing an existing doc set, so the same gaps don't get re-litigated each time.

Setup

This skill uses an optional config.json to know where your docs live and where to log audits. On first use, if docs_root is empty and you are auditing an existing doc set, ask the user (via AskUserQuestion) for the documentation directory, then save it. The skill works without config — fall back to asking inline. Never block on missing config.

Gotchas

The recurring traps of applying Diátaxis — empty structure-first scaffolding, "balancing" the four types instead of separating them, explaining inside a tutorial — are in gotchas.md. Read it before your first restructure.

Related skills

• skill-authoring — authoring Agent Skills; their SKILL.md is itself a Diátaxis problem (navigation + reference, not a tutorial).
• human-copywrite / humanize — once a doc is in the right mode, these tighten the prose so it reads naturally.
• dev-rfc / feature-spec — design and spec documents are mostly explanation; reach for those when the artifact is a proposal, not user documentation.