diataxis
Skill49 starsChanged 6 months agoMITView on GitHub
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.
11 other projects use a version of this.
Adopted by
Most recently taken up by
- rlespinasse/agent-skillstheir own version, first seen Nov 8, 2026
- pfeff/claude-skillstheir own version, first seen Nov 1, 2026
- geekatron/jerrytheir own version, first seen Nov 1, 2026
- ericmasiello/skillstheir own version, first seen Oct 20, 2026
- nstarman/skillstheir own version, first seen Oct 20, 2026
- inngest/websitetheir own version, first seen Oct 9, 2026
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- event-driven-io/emmett★ 562same name
- WebMCP-org/npm-packages★ 104same name
- inngest/website★ 51same name
- geekatron/jerry★ 37same name
- keithpatton/diataxis-agent-skill★ 18same name
- rlespinasse/agent-skills★ 13same name
- pfeff/claude-skills★ 3same name
- BlakeHastings/claude-code-artifacts★ 1same name
- nstarman/skills★ 1same name
- ericmasiello/skills★ 0same name
1 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- coding-standardsSkill
- coolify-composeSkill
- crafting-effective-readmesSkill
- english-pleaseSkill
- feature-planning-artifactsSkill
- frontend-design-principlesSkill
- grug-brained-devSkill
- html-artifactsSkill
- improveSkill
- improving-promptsSkill
- jjSkill
- reducing-entropySkill
- researching-codebasesSkill
- roadmapSkill
- roadmap-to-improve-plansSkill
- rustSkill
- salsaSkill
- skill-authoringSkill
- strategic-roadmapSkill
- svelte5Skill
- sveltekitSkill
- writing-cli-skillsSkill
- writing-error-messagesSkill
- writing-plansSkill
- writingSkill
The file
We split this skill into the rules it gives an agent
11 rules. 0 are common, 11 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 11 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Write tutorials as lessons.
- Distinctive: line 23
Use first-person plural ("We will...")
- Distinctive: line 34
Write how-to guides as practical directions for an already-competent user to achieve a specific real-world goal.
- Distinctive: line 37
Use conditional imperatives ("If you want x, do y")
- Distinctive: line 46
Write reference as technical description of the machinery.
- Distinctive: line 57
Write explanation as discursive treatment that deepens understanding.
- Distinctive: line 63
Keep closely bounded — don't absorb other types
- Distinctive: line 69
Ask two questions to classify content:
- Distinctive: line 79
Check for type mixing — does this piece try to do two things at once?
- Distinctive: line 84
Do NOT create empty four-section structures and try to fill them.
- Distinctive: line 91
Check: Not a how-to guide — the user isn't solving a specific problem, they're acquiring familiarity.
“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

