agentleFS
joshuadavidthomasjoshuadavidthomas/agent-skills/diataxis/SKILL.md

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

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
  1. Distinctive:

    Write tutorials as lessons.

    line 21
  2. Distinctive:

    Use first-person plural ("We will...")

    line 23
  3. Distinctive:

    Write how-to guides as practical directions for an already-competent user to achieve a specific real-world goal.

    line 34
  4. Distinctive:

    Use conditional imperatives ("If you want x, do y")

    line 37
  5. Distinctive:

    Write reference as technical description of the machinery.

    line 46
  6. Distinctive:

    Write explanation as discursive treatment that deepens understanding.

    line 57
  7. Distinctive:

    Keep closely bounded — don't absorb other types

    line 63
  8. Distinctive:

    Ask two questions to classify content:

    line 69
  9. Distinctive:

    Check for type mixing — does this piece try to do two things at once?

    line 79
  10. Distinctive:

    Do NOT create empty four-section structures and try to fill them.

    line 84
  11. Distinctive:

    Check: Not a how-to guide — the user isn't solving a specific problem, they're acquiring familiarity.

    line 91

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.