Write a manual

A manual explains one subject, such as a protocol, a file format, or a runtime, at one exact version. A lesson teaches a concept and moves on. A manual stays with one system until the reader can predict what it does in a case the manual never showed.

This skill gives the full method. It covers research, ranked sources, and a register of conflicts between sources. It also covers an offline capture kit, a fixed section shape, prose limits, and an audit that must report

TOTAL 0

. It works in any repository. Inside the AI Engineering from Scratch repo, the tooling already exists, and

manuals/a2a-101/

is the worked example.

When to use

The reader must predict the behavior of one system, at one version, in cases you did not show.
The subject has a specification, a schema, or a source tree that you can pin to a commit.
You can run the subject, or a faithful stand-in, offline and record its requests and responses.
The result is 60 to 100 pages with figures, and other people will maintain it.

When not to use

You teach a general concept, such as attention or retrieval. Write a lesson instead.
The subject has no version to pin, or changes every week.
You cannot run the subject and cannot record its output. A manual without captures is an essay.
You want a short how-to. A manual of fewer than about 15 sections does not need this shape.

Size of a 101 manual

Item	Target
pages	60 to 100
parts	6 to 8, plus one reference part
sections	about 25
figures	30 to 40
outcomes in `manual.json`	at least 3
takeaways per section	exactly 1 block, with at least 2 items

The worked example has 7 parts, 28 sections, 7 reference sections, and 31 figures.

Method

Pin the subject. Record the version, source URL, commit, release date, and verified date.
Rank the sources. List them in authority order: schema or proto, specification, project docs, reference SDK, capture kit.
Vendor what the license allows. Copy each quotable source unchanged into
```
research/sources/
```
, with its license file beside it.
Write the fact brief. Index every rule you will use by section and line number, in
```
research/
```
. See references/research-and-sources.md.
Open the conflict register. Give each disagreement between two sources an id (
```
D1
```
,
```
D2
```
, ...) as you find it.
Build the capture kit. Drive the subject offline and write deterministic files to
```
capture/out/
```
. See references/capture-kit.md.
Plan the contents from the specification. Name each section after one thing the reader can find in the spec.
Write
manual.json
. Fill the pin, outcomes, palette, ranked sources, quote sources, capture commands, and parts. See references/manual-json.md.
Write the front matter. Title it "How to read this manual" and follow the order in "Front matter" below.
Write one section at a time. Use the section shape below. Cut every listing from a capture file.
Draw each figure from a capture. Follow the figure must-haves below and the sibling
```
blueprint-figure
```
skill.
Build and audit. Fix every finding until the audit prints
```
TOTAL 0
```
. See references/audit.md.
Commit one section per commit. Include its figures and the captures it adds.

Plan the contents from the specification

Build the table of contents from the names the specification uses, then decide what each part proves.

Front matter. One document,
```
front.md
```
, titled "How to read this manual".
Part 1, the subject on one page. Two sections: what the subject standardizes, then one complete exchange from a capture.
Middle parts. One part per layer of the subject, such as discovery, data model, operations, bindings, security, and extensions.
Last part, implementation. Build a client and a server. Test both with the official conformance tools. Explain migration from the previous version.
Reference part. Method tables, objects, states, errors, a glossary, the sources and conflicts, and the figure index.

Each section title names one object, operation, binding, header, error, or extension from the specification. "CancelTask and terminal states" is a good title. "State machines" is not, because no specification defines an object with that name. Put a general idea in the section about the object that has it.

Front matter

front.md

covers these topics, in this order:

Who the manual is for, and what they can do after it.
How it was made, with the ranked sources table.
The capture kit.
The conventions: citation forms, listing cuts, and id shortening.
A first run that the reader can do offline.
How the parts are ordered, as an empty
```
parts
```
block.
Colour in figures, as an empty
```
palette
```
block.
Figure 0.1, which teaches the arrow and colour grammar of this manual.

Section shape

Every section file follows this order. Reference sections and the front matter need a thesis and a sources line, but no outcome sentence and no takeaways.

```
# Title
```
, with the name the specification uses.
```
> Thesis
```
, directly under the title: one sentence of at most 30 words, the claim the section proves.
An opening paragraph that starts from a concrete situation the reader has been in.
The sentence "When you finish this section, you can ..." inside the first two paragraphs.
The body:
```
##
```
subsections, definitions that start with
```
**Term:**
```
, figures, listings, rules, and tables.
Exactly one
```
takeaways
```
block, with two or more actions.
A last paragraph that starts with
```
Sources:
```
and names every file the section was written from.

A complete template is in references/section-template.md.

Fenced block kinds

Fence	Holds	Required keys
`figure`	one figure, by id	`id` , `kind` , `title` , `claim` , `caption`
`listing`	lines cut from one capture file	`title` , `source` , `lang` , optional `note` , then `---` and the lines
`rule`	one quote, checked word for word	`label` , `source` , then `---` and the quote
`takeaways`	the actions for the section	two or more `- item` lines
`parts` , `palette` , `figure-index` , `contents`	generated tables	no body

Every other fence needs a language tag. A

json

jsonl

http

, or

sse

fence must be a

listing

instead.

Markdown subset

Use only these constructs, so every edition renders the same way:

One
```
#
```
title on the first line, and the thesis quote under it.
```
##
```
and
```
###
```
headings, each with an optional
```
{#anchor}
```
.
Paragraphs, and one-level
```
-
```
or
```
1.
```
lists.
Pipe tables with a header row.
Bold, italic, and inline code.
```
{{key ref}}
```
citations,
```
[text](#s-5-3)
```
cross-references, and repository links.

Raw HTML, horizontal rules, nested lists,

####

headings, and other quote blocks fail the build. Section anchors are

s-

plus the id with dots as hyphens, such as

s-1-4

s-r-2

Listings

Cut every listing from a file in
```
capture/out/
```
. Never type a request or a response from memory.
Each listing line must appear in its source file exactly as written.
Mark a cut with
```
…
```
on its own line or inside a line.
Say what you cut in the
```
note
```
.
Name the source file in
```
source
```
, so the reader can open the full record.

Sources, quotes, and conflicts

Rank
```
sources
```
by authority. When two sources disagree, the higher one wins and the text says so.
Quote a rule word for word, then cite its key:
```
"quoted text" {{spec §3.1.5}}
```
.
Declare every citation key in
```
quoteSources
```
. Map it to a vendored file, or to
```
null
```
when the source cannot be vendored.
Paraphrase sources with a
```
null
```
key, such as an SDK. Never quote them.
When sources disagree, quote both sides in the section, say which one the manual follows, and link the register entry.
Keep the register in the sources reference section. Give it five columns: id, sources, choice, sections, and upstream status.
Never name or cite another guide, course, or book. Cite specifications, source code, papers, and the subject's own documentation.

Prose limits

Limit	Value
words in a sentence	at most 25
words in a thesis	at most 30, one sentence
words in a figure claim	at most 28, one sentence ending with a period
words in a takeaway	at most 20, an instruction in imperative mood
sentences in a paragraph	at most 6

Write in the second person, about the mechanism. Define a term once, use it the same way everywhere, and add it to the glossary. Quotes, code, and citations are exempt from the limits.

Use no semicolons, no contractions, and no em or en dashes. Never write the word

may

. Use "can", or state the condition. Avoid the banned words in references/prose-rules.md.

Figure must-haves

Use the sibling

blueprint-figure

skill to draw the figures. Every figure in a manual must also meet these rules:

Use one of nine kinds:

sequence

structure

flow

comparison

timeline

tree

state

decision

layers

Show the real system: real ids, field names, method names, and sequence numbers from a capture.
Make one claim of at most 28 words. The caption says how to read the figure, then names its capture file.
Never draw generic boxes such as "Component A", stat cards, or progress bars.
Compare two behaviors of the subject. Never compare against an earlier build.
Give each hue one meaning per manual.
```
rose
```
is failure,
```
grey
```
is outside the subject,
```
amber
```
is lifecycle,
```
teal
```
is durable state.
Draw exchanges with the eight arrow styles below. Figure 0.1 teaches the ones the manual uses.
Use
```
viewBox="0 0 640 H"
```
with H at most 760, text at least 11 units, and a file of at most 40 KB.
Put a
```
<title>
```
and a
```
<desc>
```
of at least 40 characters on the root, which has
```
role="img"
```
.
Start every
```
id
```
in the SVG with the figure id, because all figures share one page.
Write colours only as
```
var(--m-<token>, #hex)
```
, with the light value of the token as the hex.

Arrow style	Means
solid ink	a call or request
dashed ink	a reply
solid teal	a durable write
dashed amber	a state change
solid plum	a model call or compute
dashed olive	an effect outside the system
dotted indigo	a stream or an event
dashed rose	a failure

Build and audit

Inside the AI Engineering from Scratch repo, run these from the repository root:

bash

node --test site/test_manuals.js
node site/build-manuals.js
node manuals/_shared/figkit.js build manuals/<id>
node scripts/audit_manuals.js --manual <id>

Outside the repo, build your own audit from references/audit.md. It lists each check, so you can write it as one script. Fix the text, never the limit. A manual does not merge until the audit prints

TOTAL 0

Commit rules

Commit one section per commit, with its figures and the captures it adds.
Use the message
```
feat(manual/<id>): <section slug>
```
.
Never commit generated output. Inside the repo, that is
```
site/manual-<id>.html
```
,
```
site/manuals.html
```
, and
```
site/manuals-data.js
```
.
Keep
```
status
```
at
```
draft
```
until the manual is complete. A
```
ready
```
manual needs a
```
README.md
```
.
Update vendored sources only together with the
```
pin
```
in
```
manual.json
```
.

Check before you finish

```
manual.json
```
validates, and
```
pin
```
has subject, version, source, commit, date, and verified.
Every section title names one thing that the specification defines.
Every section has a thesis, an outcome sentence in its first two paragraphs, one takeaways block, and a
```
Sources:
```
line.
Every
```
json
```
,
```
jsonl
```
,
```
http
```
, and
```
sse
```
block is a
```
listing
```
with a capture source.
The capture check runs offline and reports no drift.
Every quote of 24 or more characters is found word for word in its vendored file.
Every conflict has a register id, and each section that meets it links that id.
Every figure SVG is used by a document and matches its source script.
The audit prints
```
TOTAL 0
```
.
Each commit holds one section, with the message
```
feat(manual/<id>): <section slug>
```
.

Files

references/manual-json.md: every field of
```
manual.json
```
, with a starter file.
references/section-template.md: a section skeleton with each fence kind.
references/research-and-sources.md: the fact brief, vendoring, quotes, and the conflict register.
references/capture-kit.md: how to record deterministic captures and check them for drift.
references/prose-rules.md: the limits and the full banned word list.
references/audit.md: every audit rule, and how to reproduce the audit outside the repo.

Inside the AI Engineering from Scratch repo, also see

manuals/AUTHORING.md

manuals/manual.schema.json

, and

manuals/a2a-101/

write-manual

NPX Install

Tags

SKILL.md Content