diataxis
Write, review, or organize documentation following the Diátaxis framework. Use when writing docs, reviewing docs, creating tutorials, how-to guides, reference material, or explanatory content.
What this skill does
# Diátaxis documentation framework
You write and review documentation according to the Diátaxis framework by
Daniele Procida (https://diataxis.fr). Diátaxis identifies four modes of
documentation, each serving a distinct user need. **Never mix modes within a
single document.**
The source material in `${CLAUDE_SKILL_DIR}/diataxis-documentation-framework/`
is the RST source of the Diátaxis website itself. It is structured according to
its own principles: the pages on each documentation type are reference, the
compass and workflow pages are how-to guides, the foundations and map pages are
explanation, and the start-here page is a tutorial. Study the source not just
for what it says, but for how it's written.
## The compass: classifying content
Ask two questions to determine which mode content belongs to:
| Content... | ...serves the user's... | ...belongs to |
|-------------------|-------------------------|---------------|
| informs action | acquisition of skill | tutorial |
| informs action | application of skill | how-to guide |
| informs cognition | application of skill | reference |
| informs cognition | acquisition of skill | explanation |
## The four modes at a glance
**Tutorial** — a lesson. Learning-oriented. The reader acquires skill by doing
things under your guidance. You are the teacher; all responsibility for success
is yours. Minimize explanation. Focus on concrete steps and visible results.
**How-to guide** — a recipe. Goal-oriented. The reader already has competence
and needs to accomplish a specific real-world task. No teaching, no explanation.
Address the user's problem, not the tool's features.
**Reference** — a map. Information-oriented. Austere, neutral, complete
technical description of the machinery. Structure mirrors the thing it
describes. One consults reference; one does not read it.
**Explanation** — a discussion. Understanding-oriented. Provides context,
background, reasoning, and connections. Answers "why?" questions. The only mode
where opinion, alternatives, and history belong.
## When to read the source material
Read the relevant page before writing or reviewing documentation of that type.
All paths are relative to `${CLAUDE_SKILL_DIR}/diataxis-documentation-framework/`.
| Task | Read |
|------|------|
| Quick overview of the framework | `start-here.rst` |
| Writing or reviewing a tutorial | `tutorials.rst` |
| Writing or reviewing a how-to guide | `how-to-guides.rst` |
| Writing or reviewing reference docs | `reference.rst` |
| Writing or reviewing explanatory docs | `explanation.rst` |
| Unsure what type of doc to write | `compass.rst` |
| Distinguishing tutorials from how-tos | `tutorials-how-to.rst` |
| Distinguishing reference from explanation | `reference-explanation.rst` |
| Organizing a large documentation set | `complex-hierarchies.rst` |
| Understanding the theory behind Diátaxis | `foundations.rst`, `map.rst` |
| Thinking about documentation quality | `quality.rst` |
| Workflow: applying Diátaxis iteratively | `how-to-use-diataxis.rst` |
**Do not read HTML files or images.** The canonical source material is the `.rst`
source files, and all other files in the source are of limited value for your
comprehension of the framework.
## Applying this skill
When asked to write documentation:
1. **Classify** the content using the compass table above.
2. **Read** the relevant source page for the mode you're writing in.
3. **Write** following the principles in that page.
4. **Verify** that you haven't mixed modes. If a section drifts into another
mode (e.g., explanation creeping into a how-to guide), split it out or
remove it.
When asked to review documentation:
1. **Classify** each section by mode.
2. **Read** the relevant source pages.
3. **Assess** whether each section follows the principles for its mode.
4. **Report** mode violations, mixed content, and structural issues.
$ARGUMENTS
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.