tutorial-docs
The tutorial-docs skill provides patterns for writing learning-oriented documentation that teaches beginners through guided hands-on practice following the Diataxis framework. Use this skill when creating tutorials, getting-started guides, onboarding materials, or any beginner-focused learn-by-doing content that emphasizes visible results at each step and maintains one clear path without offering alternatives.
git clone --depth 1 https://github.com/existential-birds/beagle /tmp/tutorial-docs && cp -r /tmp/tutorial-docs/plugins/beagle-docs/skills/tutorial-docs ~/.claude/skills/tutorial-docsSKILL.md
# Tutorial Documentation Skill
This skill provides patterns for writing effective tutorials following the Diataxis framework. Tutorials are learning-oriented content where the reader learns by doing under the guidance of a teacher.
**Dependency:** Use this skill with `docs-style` for core writing principles. To confirm a tutorial is the right type — rather than a how-to, reference, or explanation — see [docs-style/references/diataxis-compass.md](../docs-style/references/diataxis-compass.md).
## Purpose & Audience
**Target readers:**
- Complete beginners with no prior experience
- Users who want to learn, not accomplish a specific task
- People who need a successful first experience with the product
- Learners who benefit from guided, hands-on practice
**Tutorials are NOT:**
- How-To guides (which help accomplish specific tasks)
- Explanations (which provide understanding)
- Reference docs (which describe the system)
## Core Principles (Diataxis Framework)
### 1. Learn by Doing, Not by Reading
Tutorials teach through action, not explanation. The reader should be doing something at every moment.
| Avoid | Prefer |
|-------|--------|
| "REST APIs use HTTP methods to..." | "Run this command to make your first API call:" |
| "Authentication is important because..." | "Add your API key to authenticate:" |
| "The dashboard contains several sections..." | "Click **Create Project** in the dashboard." |
### 2. Deliver Visible Results at Every Step
After each action, tell readers exactly what they should see. This confirms success and builds confidence.
```markdown
Run the development server:
```bash
npm run dev
```
You should see:
```
> Local: http://localhost:3000
> Ready in 500ms
```
Open http://localhost:3000 in your browser. You should see a welcome page with "Hello, World!" displayed.
```
### 3. One Clear Path, Minimize Choices
Tutorials should not offer alternatives. Pick one way and guide the reader through it completely.
| Avoid | Prefer |
|-------|--------|
| "You can use npm, yarn, or pnpm..." | "Install the dependencies:" |
| "There are several ways to configure..." | "Create a config file:" |
| "Optionally, you might want to..." | [Omit optional steps entirely] |
### 4. The Teacher Takes Responsibility
If the reader fails, the tutorial failed. Anticipate problems and prevent them. Never blame the reader.
```markdown
<Warning>
Make sure you're in the project directory before running this command.
If you see "command not found", return to Step 2 to verify the installation.
</Warning>
```
### 5. Permit Repetition to Build Confidence
Repeating similar actions in slightly different contexts helps cement learning. Don't try to be efficient.
### 6. Write in the First-Person Plural
Diataxis prescribes the "we" voice for tutorials — "In this tutorial, we will build…", "Now we add…", "Let's check the output." It affirms the bond between teacher and learner: you are doing this *together*, and the teacher takes responsibility for the outcome. Reserve bare second-person imperatives ("Run this command") for the individual actions the reader performs; frame the journey itself with "we."
| Avoid | Prefer |
|-------|--------|
| "You will build a dashboard." | "In this tutorial, we'll build a dashboard." |
| "Next, configure the API." | "Now let's configure the API." |
## Tutorial Template
Use this structure for all tutorials:
```markdown
---
title: "Build your first [thing]"
description: "Learn the basics of [product] by building a working [thing]"
---
# Build Your First [Thing]
In this tutorial, we'll build a [concrete deliverable]. By the end, you'll have a working [thing] that [does something visible].
<Note>
This tutorial takes approximately [X] minutes to complete.
</Note>
## What you'll build
[Screenshot or diagram of the end result]
A [brief description of the concrete deliverable] that:
- [Visible capability 1]
- [Visible capability 2]
- [Visible capability 3]
## Prerequisites
Before starting, make sure you have:
- [Minimal requirement 1 - link to install guide if needed]
- [Minimal requirement 2]
<Tip>
New to [prerequisite]? [Link to external resource] has a quick setup guide.
</Tip>
## Step 1: [Set up your project]
[First action - always start with something that produces visible output]
```bash
[command]
```
You should see:
```
[expected output]
```
[Brief confirmation of what this means]
## Step 2: [Create your first thing]
[Next action with clear instruction]
```code
[code to add or modify]
```
Save the file. You should see [visible change].
<Note>
[Optional tip to prevent common mistakes]
</Note>
## Step 3: [Continue building]
[Continue with more steps, each producing visible output]
## Step 4: [Add the final piece]
[Bring it together with a final step]
You should now see [final visible result].
[Screenshot of completed project]
## What you've learned
In this tutorial, you:
- [Concrete skill 1 - what they can now do]
- [Concrete skill 2]
- [Concrete skill 3]
## Next steps
Now that you have a working [thing], you can:
- **[Tutorial 2 title]** - Continue learning by [next learning goal]
- **[How-to guide]** - Learn how to [specific task] with your [thing]
- **[Concepts page]** - Understand [concept] in more depth
```
## Writing Principles
### Title Conventions
- **Start with action outcomes**: "Build your first...", "Create a...", "Deploy your..."
- Focus on what they'll make, not what they'll learn
- Be concrete: "Build a chat application" not "Learn about real-time messaging"
### Step Structure
1. **Lead with the action** - don't explain before doing
2. **Show exactly what to type or click** - no ambiguity
3. **Confirm success after every step** - "You should see..."
4. **Keep steps small** - one visible change per step
### Managing Prerequisites
Tutorials are for beginners, so minimize prerequisites:
```markdown
## Prerequisites
- A computer with macOS, Windows, or Linux
- A text editor (we recommend VS Code)
- 15 mtag and push a release after the release PR is merged
create a release PR (auto-detects previous tag)
Guides architectural decisions for Deep Agents applications. Use when deciding between Deep Agents vs alternatives, choosing backend strategies, designing subagent systems, or selecting middleware approaches.
Reviews Deep Agents code for bugs, anti-patterns, and improvements. Use when reviewing code that uses create_deep_agent, backends, subagents, middleware, or human-in-the-loop patterns. Catches common configuration and usage mistakes.
Implements agents using Deep Agents. Use when building agents with create_deep_agent, configuring backends, defining subagents, adding middleware, or setting up human-in-the-loop workflows.
Guides architectural decisions for LangGraph applications. Use when deciding between LangGraph vs alternatives, choosing state management strategies, designing multi-agent systems, or selecting persistence and streaming approaches.
Reviews LangGraph code for bugs, anti-patterns, and improvements. Use when reviewing code that uses StateGraph, nodes, edges, checkpointing, or other LangGraph features. Catches common mistakes in state management, graph structure, and async patterns.
Implements stateful agent graphs using LangGraph. Use when building graphs, adding nodes/edges, defining state schemas, implementing checkpointing, handling interrupts, or creating multi-agent systems with LangGraph.