Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
126 changes: 126 additions & 0 deletions skills/diataxis/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,126 @@
---
name: diataxis
description: >
Write, review, classify, and restructure documentation using the Diataxis framework.
Diataxis defines four documentation types — tutorials, how-to guides, reference, explanation —
based on two axes: action vs. cognition, and acquisition vs. application.
Use when writing docs, reviewing docs for quality, classifying existing content into the four types,
restructuring documentation, deciding what kind of doc to write, or when asked about
"Diataxis", "documentation types", "tutorial vs how-to", "reference vs explanation",
"documentation structure", "documentation quality", or "documentation framework".
Comment on lines +4 to +10

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Description: cut roughly half. 606 chars / 77 words, and every one of them sits in the context window on every turn — a description earns harder pruning than the body.

Three issues:

  1. Identity that's already in the body. Lines 5–6 ("Diataxis defines four documentation types… based on two axes…") restate lines 46–57. A description's job is triggering, not defining.
  2. Branches written twice. reviewing docs for quality"documentation quality"; restructuring documentation"documentation structure"; classifying existing content into the four types"documentation types". Synonyms renaming one branch are duplication — they don't widen the trigger surface, they just cost tokens.
  3. Leading word buried. Diataxis is the 8th word. It's the word users actually type and the one that should do the invocation work, so front-load it.

Suggested (~300 chars):

description: >
  Diataxis documentation framework — classify, write, review, and restructure docs
  as tutorials, how-to guides, reference, or explanation. Use when writing or
  reviewing documentation, deciding which type to write, or when asked about
  "Diataxis", "tutorial vs how-to", or "reference vs explanation".

---

# Diataxis Documentation Framework

IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning for any documentation tasks. Always consult the reference files below rather than relying on general knowledge.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This instruction is undercut by the ~100 lines that follow it. Lines 46–126 are a pre-training-led summary — hand-written, unsynced, and (see the four-types table below) containing phrasings that don't appear anywhere in the corpus.

If the paraphrase goes and the pointers stay, this line becomes true and can stay. If the paraphrase stays, this line tells the agent to distrust the file it's reading.


## Source of Truth

All reference files below are symlinked from the Diataxis repo and always reflect the latest content. Read them for authoritative guidance.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 This is false the moment the PR merges.

main moved every .rst into source/ in c953482. The symlinks point at the repo root, so all 15 dangle after merge — and the merge is conflict-free, so nothing flags it:

$ git checkout -B mergetest origin/main && git merge ertembiyik/diataxis-skill
$ for f in skills/diataxis/references/*; do [ -e "$f" ] || echo "BROKEN $(basename $f)"; done
BROKEN application.rst
... 15 of 15

They resolve on this branch's base, which is why the diff looks clean.

Also worth softening "always reflect the latest content" regardless: it's true of the .rst files and false of everything below line 22. That gap is what let this branch go stale unnoticed for six months.


## Compressed Index

```
references/
├── Core
│ ├── start-here.rst — 5-min primer: the four types + two axes
│ ├── theory.rst — Full theoretical grounding

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

theory.rst is 176 words: an epigraph, three short paragraphs, and a toctree. It isn't "full theoretical grounding" — it's the landing page for the section that contains it. Same at line 40: application.rst is 255 words of intro plus a list of :doc: links.

An agent sent to either for grounding gets a table of contents, and the :doc: roles don't resolve as plain text outside Sphinx, so the links are dead ends.

The substance those two point at is already in your index — foundations.rst, map.rst, quality.rst, and the four type pages. Either drop the two landing pages or relabel them as section indexes.

│ ├── foundations.rst — Why documentation needs structure
│ ├── map.rst — The two-dimensional map (action/cognition x acquisition/application)
│ └── compass.rst — Decision tool: classify content into the four types
├── The Four Types
│ ├── tutorials.rst — Principles for learning-oriented docs (lessons, guided practice)
│ ├── how-to-guides.rst — Principles for goal-oriented docs (step-by-step task completion)
│ ├── reference.rst — Principles for information-oriented docs (austere descriptions)
│ └── explanation.rst — Principles for understanding-oriented docs (context, why, discussion)
├── Key Distinctions
│ ├── tutorials-how-to.rst — Tutorial vs how-to: the most common confusion
│ └── reference-explanation.rst — Reference vs explanation: when to describe vs discuss
└── Applying Diataxis
├── application.rst — Practical application guide
├── how-to-use-diataxis.rst — Iterative workflow: assess → decide → act → repeat
├── complex-hierarchies.rst — Handling large/complex doc structures

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 This page no longer exists. Removed deliberately in abfae1f"Tidied up some files; removed complex hierarchies page" — and it's neither at the root nor in source/ on main.

Unlike the other 14, retargeting to source/ won't fix this one. Remove this line, the pointer at line 125, and references/complex-hierarchies.rst.

└── quality.rst — Functional quality vs deep quality
```

## The Four Types at a Glance

```
│ ACTION (practical) │ COGNITION (theoretical)
──────────────┼────────────────────────┼──────────────────────────
ACQUISITION │ TUTORIAL │ EXPLANATION
(study) │ "We will..." │ "The reason is..."
│ Learning experience │ Context, why, discussion
──────────────┼────────────────────────┼──────────────────────────
APPLICATION │ HOW-TO GUIDE │ REFERENCE
(work) │ "If you want x, do y" │ "X is / X does..."
│ Task completion │ Austere description
Comment on lines +49 to +57

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The quadrant mapping is correct and matches compass.rst exactly. The exemplar phrasings are half-invented, though — which matters on a skill whose first instruction (line 15) is to prefer the sources over general knowledge:

Phrasing In the corpus?
"If you want x, do y" how-to-guides.rst:156
Austere description reference.rst:31
"We will..." ❌ appears nowhere in the repo
"The reason is..." ❌ appears nowhere in the repo

Meanwhile map.rst:72–76 already carries the framework's own canonical quadrant mnemonic, and it's the widely-cited one:

"Can you teach me to…?" / "How do I…?" / "What is…?" / "Why…?"

Swapping the two invented rows for the repo's own line costs nothing, can't drift, and reinforces the vocabulary a reader will meet in the docs themselves. map.rst also gives the oriented to row — learning / goals / information / understanding — if you want a second line per cell.

```

## Compass — Classify Any Content

Ask two questions:
1. Does it inform **action** (do something) or **cognition** (understand something)?
2. Does it serve **acquisition** (learning/study) or **application** (working/doing)?

Result: action+acquisition=tutorial | action+application=how-to | cognition+application=reference | cognition+acquisition=explanation

For full decision logic, read `references/compass.rst`.

## Quick Rules Per Type

### Tutorials
- Provide a learning experience through doing, not teaching
- Show the goal upfront, deliver visible results early
- Use "We will..." language; minimize explanation (link to it)
- Must be perfectly reliable — learner must never get stuck
- Read `references/tutorials.rst` for full principles

### How-to Guides
- Address real-world goals, not machinery operations
- Assume competence; focus purely on action
- Title = exactly what the guide shows how to do
- Handle edge cases; omit the unnecessary
- Read `references/how-to-guides.rst` for full principles

### Reference
- Describe and only describe — neutral, austere, complete
- Mirror the structure of the thing being documented
- Adopt standard, consistent patterns throughout
- Provide examples for illustration, not explanation
- Read `references/reference.rst` for full principles

### Explanation
- Make connections, provide context, explain why
- Admit opinion and perspective; consider alternatives
- Can discuss history, design decisions, trade-offs
- Keep closely bounded to the topic
- Read `references/explanation.rst` for full principles
Comment on lines +72 to +98

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This block is the second source of truth, and it has already drifted. Nothing syncs it with the files it summarises. Coverage against the Key principles sections in source/ on main today:

  • Reference — 4/4 ✅
  • Explanation — 4/5, missing Talk about the subject (the principle that defines explanation as being around a topic — arguably the one that most distinguishes it from reference)
  • How-to guides — 4/6, missing Describe a logical sequence and Seek flow
  • Tutorials — 3/6, missing Maintain a narrative of the expected, Point out what the learner should notice, and Encourage and permit repetition

Nobody edited this file for that to happen; the sources moved. That's the same failure as the broken symlinks, just slower.

Separately — the five pointers here are weakly worded. "Read references/tutorials.rst for full principles" states no condition for reading it, so whether the agent actually goes is a coin-flip. A pointer's wording, not its target, decides when and how reliably the material gets reached. Give each a trigger:

Before drafting or reviewing a tutorial, read `references/tutorials.rst` in full.

Same for lines 110–111 and 124–126.

If you take option 1 from the review (drop the paraphrase, keep index + pointers), this whole block collapses to four conditional pointers and the drift surface goes with it.


## Common Mistakes

| Mistake | Fix |
|---|---|
| Tutorial explains too much | Move explanation to explanation docs, link to it |
| How-to teaches background | Strip to action steps only |
| Reference includes opinions | Move discussion to explanation |
| Explanation gives step-by-step | Move procedure to how-to guide |
| Mixing types in one doc | Split into separate docs by type |

For the critical tutorial-vs-howto distinction, read `references/tutorials-how-to.rst`.
For reference-vs-explanation, read `references/reference-explanation.rst`.

## Workflow for Applying Diataxis

1. Pick any piece of documentation
2. Use the compass to classify it (action/cognition x acquisition/application)
3. Assess: does it serve the identified user need well?
4. Decide one single improvement action
5. Do it and ship it
6. Repeat
Comment on lines +115 to +120

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This diverges from how-to-use-diataxis.rst, which prescribes four steps, not six:

Choose somethingAssess itDecide what to doDo it → back to the beginning

Step 2 here ("Use the compass to classify it") isn't part of that cycle. The compass is presented in compass.rst as a course-correction tool for when you're troubled by doubt — "The compass forces you to stop and reconsider" — not as a mandatory classification pass on every iteration. Making it step 2 changes the method.

Step 3 also flattens the four questions the source actually asks:

What user need is represented by this? How well does it serve that need? What can be added, moved, removed or changed to serve that need better? Do its language and logic meet the requirements of this mode of documentation?

The bolded one is what makes step 4 answerable; without it, "decide one single improvement action" has nothing to draw on.

Two craft points on top of the accuracy one: no step carries a checkable completion criterion, which is what stops an agent declaring a step done and sliding to the next; and "Repeat" has no exit condition, so the loop never terminates. Since this section is the skill's only sequence of steps, it's where a criterion buys the most — e.g. step 4 as "name exactly one action, and the user need it serves", which is both checkable and faithful to the source.


Do not plan a grand restructuring. Work iteratively, one improvement at a time. Documentation is never finished but always complete.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Steering by prohibition backfires — naming "grand restructuring" drags it into context and makes it more available, not less. The negation is a weak modifier over a strongly-activated concept.

The source already gives you the positive form as a heading: Work one step at a time. And how-to-use-diataxis.rst supplies the operative detail:

every step in the right direction is worth publishing immediately

Suggested:

Work one improvement at a time, and publish each before starting the next.
Documentation is never finished but always complete.

(The .rst prose uses negation freely — "Don't do that. It's horrible." — but that's prose written to persuade a human. This is a prompt steering a model, and the two behave differently.)

The second half of the line is a faithful quote from Complete, not finished — no change needed there.


For full workflow guidance, read `references/how-to-use-diataxis.rst`.
For complex documentation structures, read `references/complex-hierarchies.rst`.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Second reference to the deleted complex-hierarchies page — see line 42. Remove.

For quality theory (functional vs deep quality), read `references/quality.rst`.
1 change: 1 addition & 0 deletions skills/diataxis/references/application.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/compass.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/complex-hierarchies.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/explanation.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/foundations.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/how-to-guides.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/how-to-use-diataxis.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/map.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/quality.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/reference-explanation.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/reference.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/start-here.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/theory.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/tutorials-how-to.rst
1 change: 1 addition & 0 deletions skills/diataxis/references/tutorials.rst