docs

Source documentation, not instructions for this website. Review permissions before running any commands.

Find docs
  → read neighbors
  → Phase 1: readers + pages
  → PERSONA GATE (show the list, then stop)
  → TONE GATE (ask, then stop)          [when writing pages]
  → load simple-english + i-have-adhd   [when writing pages]
  → Phase 2: write

Bad: one page
  interrupts.md   (overview + simple case + many interrupts + custom, all crammed in)

Good: a small set of linked pages
  interrupts/index.md            what it is, when to use it, links out
  interrupts/basic.md            one interrupt, start to finish
  interrupts/multiple.md         several interrupts in a flow
  interrupts/custom.md           build your own

Bad:
  Call useInterrupts() and pass a resolver. The resolver runs once per
  pending item inside a transaction...

Good:
  Some tool calls shouldn't run without a human saying yes: moving money,
  deleting data. An interrupt pauses the run for that decision, then picks up
  where it left off. Here is how to gate a tool behind an approval:

  [code]

name: docs
description: Use when writing, editing, or organizing documentation, when planning what docs a feature needs, and whenever planning or implementing a new feature or change in a repo (docs ship with the code). Also use when tempted to write docs without showing the discovered readers to the user, without asking for tone, or without loading simple-english and i-have-adhd. Triggers on "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.

---
name: docs
description: Use when writing, editing, or organizing documentation, when planning what docs a feature needs, and whenever planning or implementing a new feature or change in a repo (docs ship with the code). Also use when tempted to write docs without showing the discovered readers to the user, without asking for tone, or without loading simple-english and i-have-adhd. Triggers on "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.
---

# docs

Write docs a real person wants to read. Short, plain, built around someone trying to do a real thing.

"Document feature X" is not the job. "Help someone do Y with X" is the job.

Work in two phases. First plan the story: who reads this, what they want, and how many pages it should be. Then write.

The plan is not private. The user must see the readers and must choose the tone before any page is written.

```text
Find docs
  → read neighbors
  → Phase 1: readers + pages
  → PERSONA GATE (show the list, then stop)
  → TONE GATE (ask, then stop)          [when writing pages]
  → load simple-english + i-have-adhd   [when writing pages]
  → Phase 2: write
```

A doc-impact list in a feature plan still runs the persona gate. It does not run the tone gate or load the writing skills until pages are actually written.

## When to run

Docs ship with the code. Run this skill at three moments, not only when asked.

- Someone asks for docs. Write them.
- Planning a feature or change in a repo. Before the plan is done, list which docs are new and which need updating. This doc-impact list is part of the plan, the same as the code changes. Name the reader for each page.
- Finishing an implementation. Write or update those docs before you call the work done. A change to how something behaves that ships no doc change is not finished.

## Required skills for the final pages

`simple-english` and `i-have-adhd` are prerequisites. They apply to the documentation pages, not to this planning chat.

Load both immediately before writing page content. Use the Skill tool if this harness has one. If it does not, Read each skill's SKILL.md from the local skills directory. Do not write pages from memory of those skills.

If either skill is missing, stop and tell the user. Do not write the pages without them.

How they compose:

- This skill owns who the page is for, the page split, problem-then-fix, show-don't-tell, no history leak, forbidden glyphs, and neighbor structure.
- `simple-english` owns the sentences. Use pragmatic mode. Run its self-check before you call a page done.
- `i-have-adhd` owns the shape of the page: next action first, numbered steps, lists capped at 5 (split must vs later, or split the page), no preamble, a visible win at the end.

When `i-have-adhd` is loaded from this skill, apply it to the pages only. Do not switch the rest of the session into ADHD mode. The persistence section of `i-have-adhd` does not apply here.

## Find the docs first

Before writing anything, find where docs live.

1. Look for a docs folder. Check `docs/` first, then `documentation/`, `content/docs/`, `site/`, `website/docs/`.
2. Found nothing? Ask the user where docs should go. Do not guess and do not create a folder on a hunch.
3. Open 2 or 3 existing pages near where the new content belongs. Read them for copy, structure, frontmatter fields, and components. Note the apparent tone as a *candidate* for the tone gate. Do not adopt it yet.
4. Note which components the site already uses (steps, tabs, callouts, cards, accordions, code groups, and so on). Different sites have different ones.
5. Reuse those components to tell the story. If the site has a steps component, use it for walkthroughs. If it has tabs, use them for framework variations. If the site has none, use plain markdown. Never invent a component the site does not have.

If there is no page like the one you are about to write, read the closest one you can find and match it.

### What "match the neighbors" covers, and what it does not

Matching neighbors is about **copy, structure, frontmatter, and components**: whether headings are sentence case, how much setup a section gets, which components carry the walkthrough, how code samples are introduced, what the frontmatter fields are.

It is **not** a substitute for the tone gate. Neighbors can suggest a default. They cannot answer for the user.

It is **not** permission to copy a neighbor's bad habits. Everything in [Forbidden](#forbidden) and every rule in this skill still applies to the content you write, no matter what the surrounding pages do. An existing page full of em dashes does not license one more.

So: never reason "the other pages do it, so I will too" about a rule this skill states. If existing pages break a rule and you think the whole set should be brought in line, that is a separate cleanup to raise with the user, not something to settle by quietly matching the violation.

## Phase 1: plan the story

Do this before you write a word of content.

1. List who reads this and what each one wants. A person building on a React SPA, a person on a server-rendered app, someone who just wants a quick demo, someone extending the internals. Do not stop at the first reader.
2. Write one user story per reader: "As a X, I want to Y, so I can Z."
3. Turn stories into pages. One journey is one page. Different journeys are different pages. A feature with three real journeys is three pages plus maybe a short overview, not one giant page.
4. Check every reader has a path. A reader with no page is a hole in the plan. Add a page or a route for them.

The page split comes out of this step. Do not skip it.

### Gate: show the personas

<HARD-GATE>
The user must see the list. Listing readers in a thought, a todo, or a buried plan is not this gate.

After step 4, send a message that contains only:

1. Each reader, one user story, and the page you will write for them.
2. One question: confirm, drop a reader, or add one.

If the harness has an AskQuestion (or similar) tool, use it for that question. If it does not, use a numbered list.

Then pick one path:

**Default: stop.** This message is the entire turn. End the turn. Do not write files. Do not start Phase 2. Do not say you will proceed unless they object.

**Skip the wait: continue in this same turn.** Use this path only when one of these is true:

- This conversation already has the user's confirmation of this persona list.
- The user said "use sane defaults", "just write it", or "don't ask questions". Still SHOW the list in this turn, then continue.
- The change is a tiny copy edit: typo, broken link, code-fence language, or a factual fix. No new page, no new section, no rewrite of a journey.

On this path, do not end the turn. After you show the list (or after a tiny copy edit, with no list), continue to the next step.

These are not skips:

- "The readers are obvious."
- "The user asked for docs, so they do not want a question."
- "I already named them in the plan."
- "There is only one reader."
- "This is part of implementing a feature, keep going."

Writing docs is why this gate exists. It is not a reason to skip it.
</HARD-GATE>

## Less is more: split, do not cram

Do not force thousands of words into one page. Long pages hide the answer.

When a topic has several angles, give each its own short page and link them. A reader lands on the overview, then clicks into the exact thing they need.

Example. A feature for tool interrupts:

```text
Bad: one page
  interrupts.md   (overview + simple case + many interrupts + custom, all crammed in)

Good: a small set of linked pages
  interrupts/index.md            what it is, when to use it, links out
  interrupts/basic.md            one interrupt, start to finish
  interrupts/multiple.md         several interrupts in a flow
  interrupts/custom.md           build your own
```

Each page is short and does one thing. The overview stitches them into a story.

## Gate: ask for tone

This gate sits between Phase 1 and Phase 2. Run it before you write any page. Do not nest it inside Phase 2.

<HARD-GATE>
This gate runs before any page content is written. It does not run for a doc-impact list that is only a plan.

Neighbors can suggest a default. They cannot answer for the user.

Send a message that contains only:

1. The tone you inferred from neighboring pages, in one line (how formal, how much setup, second person or not).
2. One question with options: use that tone, more casual, more formal, or the user names another.

If the harness has an AskQuestion (or similar) tool, use it. If it does not, use a numbered list.

Then pick one path:

**Default: stop.** This message is the entire turn. End the turn. Do not write page content.

**Skip the wait: continue in this same turn.** Use this path only when one of these is true:

- This conversation already has the user's tone choice, including an explicit "match the existing pages".
- The user said "use sane defaults", "just write it", or "don't ask questions". Still STATE the inferred tone in one line, then continue.
- Tiny copy edit, same carve-out as the persona gate.

On this path, do not end the turn. After you state the tone (or after a tiny copy edit, with no question), continue to Phase 2.

These are not skips:

- "I can tell from the neighbors."
- "The site already has a voice."
- "Tone does not matter for a reference page."
- "I'll match neighbors and mention it later."
</HARD-GATE>

## Phase 2: write like a human

Do not write page content until the persona gate has passed, the tone gate has passed, and `simple-english` plus `i-have-adhd` are loaded.

The tone gate is the heading above this one. Run that gate first. Then load the two skills. Then write.

Legibility is the goal, above everything else.

- Keep it digestible. No walls of text, no huge paragraphs. Break ideas into small pieces. Give the smallest amount of info that does the job.
- Sentences follow `simple-english` (pragmatic mode). Do not inline a weaker substitute.
- Keep markdown light. Lists are fine. Bold headings on every line are not. Let the words carry the page.
- Prefer plain ASCII and normal keyboard characters over fancy glyphs. Write the way a person types.
- Second person, action first. Start with what the reader has now and what they will have at the end. No "In this guide we will explore..." openings. Just start.
- Shape the page with `i-have-adhd`: the first line is something the reader can do, multi-step work is numbered, a list longer than 5 is split, the page ends on a visible win.

### Lead with the problem, then solve it

Every page opens with the problem the reader came for, in their own words, before any API. Name the situation they are stuck in. Then say in a sentence or two how the feature solves it. Only after that do you go into the technical parts and the code.

A reader who sees the problem first knows in seconds whether they are on the right page. A reader who hits an API signature first has to reverse-engineer what it is even for.

The first line of the how is the next action (from `i-have-adhd`). The problem still comes first so they know they are on the right page.

```text
Bad:
  Call useInterrupts() and pass a resolver. The resolver runs once per
  pending item inside a transaction...

Good:
  Some tool calls shouldn't run without a human saying yes: moving money,
  deleting data. An interrupt pauses the run for that decision, then picks up
  where it left off. Here is how to gate a tool behind an approval:

  [code]
```

The order for a guide is problem, one-line fix, then the how (steps, snippets, API). Keep the problem to a couple of sentences, not a background essay. The code shows how it is solved, so do not narrate the solution in prose first.

### Show, do not tell

Do not explain in four paragraphs what one sentence and a code block can show. Readers grasp a diff or a snippet faster than prose.

```text