[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ERJ6CJA2XZ6SHYRQSPEEBX":3,"skill-same:01M6ERJ6CJA2XZ6SHYRQSPEEBX":104},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6ERJ6CJA2XZ6SHYRQSPEEBX","write-manual",null,"Writes a long technical manual that explains one subject at one pinned version, from its purpose to each request and response. Every listing comes from an offline capture, every claim traces to a ranked source, and an audit must report TOTAL 0. Use it for \"write a manual\", \"write a 101 manual for \u003Csubject>\", \"manual.json\", \"add a manual section\", \"build a capture kit\", \"audit the manual\", or \"pin a spec version and document it\".","rohitg00\u002Fai-engineering-from-scratch","rohitg00","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F48523873?v=4","01M6ERFX7W55NRHW3AV85T2MM8","Rohit Ghumare","01M6ERFXCHT482XQFVY40TM2FN",78488,"MIT","https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"write","manual","write manual","long","listing","section","request","source","for","at","kit","specifications","manuals","technical-writing","add","writing","claim","build","document","version","use","technical","pin","json","audit","offline","report","documentation","2026-11-10 10:12:30",false,"---\nname: write-manual\nversion: 1.0.0\ndescription: >\n  Writes a long technical manual that explains one subject at one pinned version, from its purpose to each request and response.\n  Every listing comes from an offline capture, every claim traces to a ranked source, and an audit must report TOTAL 0.\n  Use it for \"write a manual\", \"write a 101 manual for \u003Csubject>\", \"manual.json\", \"add a manual section\",\n  \"build a capture kit\", \"audit the manual\", or \"pin a spec version and document it\".\ntags: [manuals, documentation, specifications, technical-writing, audit]\n---\n\n# Write a manual\n\nA 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.\n\nThis 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\u002Fa2a-101\u002F` is the worked example.\n\n## When to use\n\n- The reader must predict the behavior of one system, at one version, in cases you did not show.\n- The subject has a specification, a schema, or a source tree that you can pin to a commit.\n- You can run the subject, or a faithful stand-in, offline and record its requests and responses.\n- The result is 60 to 100 pages with figures, and other people will maintain it.\n\n## When not to use\n\n- You teach a general concept, such as attention or retrieval. Write a lesson instead.\n- The subject has no version to pin, or changes every week.\n- You cannot run the subject and cannot record its output. A manual without captures is an essay.\n- You want a short how-to. A manual of fewer than about 15 sections does not need this shape.\n\n## Size of a 101 manual\n\n| Item | Target |\n|---|---|\n| pages | 60 to 100 |\n| parts | 6 to 8, plus one reference part |\n| sections | about 25 |\n| figures | 30 to 40 |\n| outcomes in `manual.json` | at least 3 |\n| takeaways per section | exactly 1 block, with at least 2 items |\n\nThe worked example has 7 parts, 28 sections, 7 reference sections, and 31 figures.\n\n## Method\n\n1. **Pin the subject.** Record the version, source URL, commit, release date, and verified date.\n2. **Rank the sources.** List them in authority order: schema or proto, specification, project docs, reference SDK, capture kit.\n3. **Vendor what the license allows.** Copy each quotable source unchanged into `research\u002Fsources\u002F`, with its license file beside it.\n4. **Write the fact brief.** Index every rule you will use by section and line number, in `research\u002F`. See [references\u002Fresearch-and-sources.md](references\u002Fresearch-and-sources.md).\n5. **Open the conflict register.** Give each disagreement between two sources an id (`D1`, `D2`, ...) as you find it.\n6. **Build the capture kit.** Drive the subject offline and write deterministic files to `capture\u002Fout\u002F`. See [references\u002Fcapture-kit.md](references\u002Fcapture-kit.md).\n7. **Plan the contents from the specification.** Name each section after one thing the reader can find in the spec.\n8. **Write `manual.json`.** Fill the pin, outcomes, palette, ranked sources, quote sources, capture commands, and parts. See [references\u002Fmanual-json.md](references\u002Fmanual-json.md).\n9. **Write the front matter.** Title it \"How to read this manual\" and follow the order in \"Front matter\" below.\n10. **Write one section at a time.** Use the section shape below. Cut every listing from a capture file.\n11. **Draw each figure from a capture.** Follow the figure must-haves below and the sibling `blueprint-figure` skill.\n12. **Build and audit.** Fix every finding until the audit prints `TOTAL 0`. See [references\u002Faudit.md](references\u002Faudit.md).\n13. **Size commits by judgment.** A section with its figures and the captures it adds is a good unit.\n\n## Plan the contents from the specification\n\nBuild the table of contents from the names the specification uses, then decide what each part proves.\n\n- **Front matter.** One document, `front.md`, titled \"How to read this manual\".\n- **Part 1, the subject on one page.** Two sections: what the subject standardizes, then one complete exchange from a capture.\n- **Middle parts.** One part per layer of the subject, such as discovery, data model, operations, bindings, security, and extensions.\n- **Last part, implementation.** Build a client and a server. Test both with the official conformance tools. Explain migration from the previous version.\n- **Reference part.** Method tables, objects, states, errors, a glossary, the sources and conflicts, and the figure index.\n\nEach 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.\n\n## Front matter\n\n`front.md` covers these topics, in this order:\n\n1. Who the manual is for, and what they can do after it.\n2. How it was made, with the ranked sources table.\n3. The capture kit.\n4. The conventions: citation forms, listing cuts, and id shortening.\n5. A first run that the reader can do offline.\n6. How the parts are ordered, as an empty `parts` block.\n7. Colour in figures, as an empty `palette` block.\n8. Figure 0.1, which teaches the arrow and colour grammar of this manual.\n\n## Section shape\n\nEvery 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.\n\n1. `# Title`, with the name the specification uses.\n2. `> Thesis`, directly under the title: one sentence of at most 30 words, the claim the section proves.\n3. An opening paragraph that starts from a concrete situation the reader has been in.\n4. The sentence \"When you finish this section, you can ...\" inside the first two paragraphs.\n5. The body: `##` subsections, definitions that start with `**Term:**`, figures, listings, rules, and tables.\n6. Exactly one `takeaways` block, with two or more actions.\n7. A last paragraph that starts with `Sources:` and names every file the section was written from.\n\nA complete template is in [references\u002Fsection-template.md](references\u002Fsection-template.md).\n\n## Fenced block kinds\n\n| Fence | Holds | Required keys |\n|---|---|---|\n| `figure` | one figure, by id | `id`, `kind`, `title`, `claim`, `caption` |\n| `listing` | lines cut from one capture file | `title`, `source`, `lang`, optional `note`, then `---` and the lines |\n| `rule` | one quote, checked word for word | `label`, `source`, then `---` and the quote |\n| `takeaways` | the actions for the section | two or more `- item` lines |\n| `parts`, `palette`, `figure-index`, `contents` | generated tables | no body |\n\nEvery other fence needs a language tag. A `json`, `jsonl`, `http`, or `sse` fence must be a `listing` instead.\n\n## Markdown subset\n\nUse only these constructs, so every edition renders the same way:\n\n- One `#` title on the first line, and the thesis quote under it.\n- `##` and `###` headings, each with an optional `{#anchor}`.\n- Paragraphs, and one-level `-` or `1.` lists.\n- Pipe tables with a header row.\n- Bold, italic, and inline code.\n- `{{key ref}}` citations, `[text](#s-5-3)` cross-references, and repository links.\n\nRaw 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` or `s-r-2`.\n\n## Listings\n\n- Cut every listing from a file in `capture\u002Fout\u002F`. Never type a request or a response from memory.\n- Each listing line must appear in its source file exactly as written.\n- Mark a cut with `…` on its own line or inside a line.\n- Say what you cut in the `note`.\n- Name the source file in `source`, so the reader can open the full record.\n\n## Sources, quotes, and conflicts\n\n- Rank `sources` by authority. When two sources disagree, the higher one wins and the text says so.\n- Quote a rule word for word, then cite its key: `\"quoted text\" {{spec §3.1.5}}`.\n- Declare every citation key in `quoteSources`. Map it to a vendored file, or to `null` when the source cannot be vendored.\n- Paraphrase sources with a `null` key, such as an SDK. Never quote them.\n- When sources disagree, quote both sides in the section, say which one the manual follows, and link the register entry.\n- Keep the register in the sources reference section. Give it five columns: id, sources, choice, sections, and upstream status.\n- Never name or cite another guide, course, or book. Cite specifications, source code, papers, and the subject's own documentation.\n\n## Prose limits\n\n| Limit | Value |\n|---|---|\n| words in a sentence | at most 25 |\n| words in a thesis | at most 30, one sentence |\n| words in a figure claim | at most 28, one sentence ending with a period |\n| words in a takeaway | at most 20, an instruction in imperative mood |\n| sentences in a paragraph | at most 6 |\n\nWrite 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.\n\nUse 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\u002Fprose-rules.md](references\u002Fprose-rules.md).\n\n## Figure must-haves\n\nUse the sibling `blueprint-figure` skill to draw the figures. Every figure in a manual must also meet these rules:\n\n- Use one of nine kinds: `sequence`, `structure`, `flow`, `comparison`, `timeline`, `tree`, `state`, `decision`, `layers`.\n- Show the real system: real ids, field names, method names, and sequence numbers from a capture.\n- Make one claim of at most 28 words. The caption says how to read the figure, then names its capture file.\n- Never draw generic boxes such as \"Component A\", stat cards, or progress bars.\n- Compare two behaviors of the subject. Never compare against an earlier build.\n- Give each hue one meaning per manual. `rose` is failure, `grey` is outside the subject, `amber` is lifecycle, `teal` is durable state.\n- Draw exchanges with the eight arrow styles below. Figure 0.1 teaches the ones the manual uses.\n- Use `viewBox=\"0 0 640 H\"` with H at most 760, text at least 11 units, and a file of at most 40 KB.\n- Put a `\u003Ctitle>` and a `\u003Cdesc>` of at least 40 characters on the root, which has `role=\"img\"`.\n- Start every `id` in the SVG with the figure id, because all figures share one page.\n- Write colours only as `var(--m-\u003Ctoken>, #hex)`, with the light value of the token as the hex.\n\n| Arrow style | Means |\n|---|---|\n| solid ink | a call or request |\n| dashed ink | a reply |\n| solid teal | a durable write |\n| dashed amber | a state change |\n| solid plum | a model call or compute |\n| dashed olive | an effect outside the system |\n| dotted indigo | a stream or an event |\n| dashed rose | a failure |\n\n## Build and audit\n\nInside the AI Engineering from Scratch repo, run these from the repository root:\n\n```bash\nnode --test site\u002Ftest_manuals.js\nnode site\u002Fbuild-manuals.js\nnode manuals\u002F_shared\u002Ffigkit.js build manuals\u002F\u003Cid>\nnode scripts\u002Faudit_manuals.js --manual \u003Cid>\n```\n\nOutside the repo, build your own audit from [references\u002Faudit.md](references\u002Faudit.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`.\n\n## Commit rules\n\n- Size commits by judgment. A section with its figures and the captures it adds is a good unit. A small fix across sections can be one commit.\n- Use the message `feat(manual\u002F\u003Cid>): \u003Csection slug>`.\n- Never commit generated output. Inside the repo, that is `site\u002Fmanual-\u003Cid>.html`, `site\u002Fmanuals.html`, and `site\u002Fmanuals-data.js`.\n- Keep `status` at `draft` until the manual is complete. A `ready` manual needs a `README.md`.\n- Update vendored sources only together with the `pin` in `manual.json`.\n\n## Check before you finish\n\n- [ ] `manual.json` validates, and `pin` has subject, version, source, commit, date, and verified.\n- [ ] Every section title names one thing that the specification defines.\n- [ ] Every section has a thesis, an outcome sentence in its first two paragraphs, one takeaways block, and a `Sources:` line.\n- [ ] Every `json`, `jsonl`, `http`, and `sse` block is a `listing` with a capture source.\n- [ ] The capture check runs offline and reports no drift.\n- [ ] Every quote of 24 or more characters is found word for word in its vendored file.\n- [ ] Every conflict has a register id, and each section that meets it links that id.\n- [ ] Every figure SVG is used by a document and matches its source script.\n- [ ] The audit prints `TOTAL 0`.\n- [ ] Commits are sized by judgment, with messages such as `feat(manual\u002F\u003Cid>): \u003Csection slug>`.\n\n## Files\n\n- [references\u002Fmanual-json.md](references\u002Fmanual-json.md): every field of `manual.json`, with a starter file.\n- [references\u002Fsection-template.md](references\u002Fsection-template.md): a section skeleton with each fence kind.\n- [references\u002Fresearch-and-sources.md](references\u002Fresearch-and-sources.md): the fact brief, vendoring, quotes, and the conflict register.\n- [references\u002Fcapture-kit.md](references\u002Fcapture-kit.md): how to record deterministic captures and check them for drift.\n- [references\u002Fprose-rules.md](references\u002Fprose-rules.md): the limits and the full banned word list.\n- [references\u002Faudit.md](references\u002Faudit.md): every audit rule, and how to reproduce the audit outside the repo.\n- Inside the AI Engineering from Scratch repo, also see `manuals\u002FAUTHORING.md`, `manuals\u002Fmanual.schema.json`, and `manuals\u002Fa2a-101\u002F`.\n","# Write a manual\n\nA 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.\n\nThis 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\u002Fa2a-101\u002F` is the worked example.\n\n## When to use\n\n- The reader must predict the behavior of one system, at one version, in cases you did not show.\n- The subject has a specification, a schema, or a source tree that you can pin to a commit.\n- You can run the subject, or a faithful stand-in, offline and record its requests and responses.\n- The result is 60 to 100 pages with figures, and other people will maintain it.\n\n## When not to use\n\n- You teach a general concept, such as attention or retrieval. Write a lesson instead.\n- The subject has no version to pin, or changes every week.\n- You cannot run the subject and cannot record its output. A manual without captures is an essay.\n- You want a short how-to. A manual of fewer than about 15 sections does not need this shape.\n\n## Size of a 101 manual\n\n| Item | Target |\n|---|---|\n| pages | 60 to 100 |\n| parts | 6 to 8, plus one reference part |\n| sections | about 25 |\n| figures | 30 to 40 |\n| outcomes in `manual.json` | at least 3 |\n| takeaways per section | exactly 1 block, with at least 2 items |\n\nThe worked example has 7 parts, 28 sections, 7 reference sections, and 31 figures.\n\n## Method\n\n1. **Pin the subject.** Record the version, source URL, commit, release date, and verified date.\n2. **Rank the sources.** List them in authority order: schema or proto, specification, project docs, reference SDK, capture kit.\n3. **Vendor what the license allows.** Copy each quotable source unchanged into `research\u002Fsources\u002F`, with its license file beside it.\n4. **Write the fact brief.** Index every rule you will use by section and line number, in `research\u002F`. See [references\u002Fresearch-and-sources.md](references\u002Fresearch-and-sources.md).\n5. **Open the conflict register.** Give each disagreement between two sources an id (`D1`, `D2`, ...) as you find it.\n6. **Build the capture kit.** Drive the subject offline and write deterministic files to `capture\u002Fout\u002F`. See [references\u002Fcapture-kit.md](references\u002Fcapture-kit.md).\n7. **Plan the contents from the specification.** Name each section after one thing the reader can find in the spec.\n8. **Write `manual.json`.** Fill the pin, outcomes, palette, ranked sources, quote sources, capture commands, and parts. See [references\u002Fmanual-json.md](references\u002Fmanual-json.md).\n9. **Write the front matter.** Title it \"How to read this manual\" and follow the order in \"Front matter\" below.\n10. **Write one section at a time.** Use the section shape below. Cut every listing from a capture file.\n11. **Draw each figure from a capture.** Follow the figure must-haves below and the sibling `blueprint-figure` skill.\n12. **Build and audit.** Fix every finding until the audit prints `TOTAL 0`. See [references\u002Faudit.md](references\u002Faudit.md).\n13. **Size commits by judgment.** A section with its figures and the captures it adds is a good unit.\n\n## Plan the contents from the specification\n\nBuild the table of contents from the names the specification uses, then decide what each part proves.\n\n- **Front matter.** One document, `front.md`, titled \"How to read this manual\".\n- **Part 1, the subject on one page.** Two sections: what the subject standardizes, then one complete exchange from a capture.\n- **Middle parts.** One part per layer of the subject, such as discovery, data model, operations, bindings, security, and extensions.\n- **Last part, implementation.** Build a client and a server. Test both with the official conformance tools. Explain migration from the previous version.\n- **Reference part.** Method tables, objects, states, errors, a glossary, the sources and conflicts, and the figure index.\n\nEach 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.\n\n## Front matter\n\n`front.md` covers these topics, in this order:\n\n1. Who the manual is for, and what they can do after it.\n2. How it was made, with the ranked sources table.\n3. The capture kit.\n4. The conventions: citation forms, listing cuts, and id shortening.\n5. A first run that the reader can do offline.\n6. How the parts are ordered, as an empty `parts` block.\n7. Colour in figures, as an empty `palette` block.\n8. Figure 0.1, which teaches the arrow and colour grammar of this manual.\n\n## Section shape\n\nEvery 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.\n\n1. `# Title`, with the name the specification uses.\n2. `> Thesis`, directly under the title: one sentence of at most 30 words, the claim the section proves.\n3. An opening paragraph that starts from a concrete situation the reader has been in.\n4. The sentence \"When you finish this section, you can ...\" inside the first two paragraphs.\n5. The body: `##` subsections, definitions that start with `**Term:**`, figures, listings, rules, and tables.\n6. Exactly one `takeaways` block, with two or more actions.\n7. A last paragraph that starts with `Sources:` and names every file the section was written from.\n\nA complete template is in [references\u002Fsection-template.md](references\u002Fsection-template.md).\n\n## Fenced block kinds\n\n| Fence | Holds | Required keys |\n|---|---|---|\n| `figure` | one figure, by id | `id`, `kind`, `title`, `claim`, `caption` |\n| `listing` | lines cut from one capture file | `title`, `source`, `lang`, optional `note`, then `---` and the lines |\n| `rule` | one quote, checked word for word | `label`, `source`, then `---` and the quote |\n| `takeaways` | the actions for the section | two or more `- item` lines |\n| `parts`, `palette`, `figure-index`, `contents` | generated tables | no body |\n\nEvery other fence needs a language tag. A `json`, `jsonl`, `http`, or `sse` fence must be a `listing` instead.\n\n## Markdown subset\n\nUse only these constructs, so every edition renders the same way:\n\n- One `#` title on the first line, and the thesis quote under it.\n- `##` and `###` headings, each with an optional `{#anchor}`.\n- Paragraphs, and one-level `-` or `1.` lists.\n- Pipe tables with a header row.\n- Bold, italic, and inline code.\n- `{{key ref}}` citations, `[text](#s-5-3)` cross-references, and repository links.\n\nRaw 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` or `s-r-2`.\n\n## Listings\n\n- Cut every listing from a file in `capture\u002Fout\u002F`. Never type a request or a response from memory.\n- Each listing line must appear in its source file exactly as written.\n- Mark a cut with `…` on its own line or inside a line.\n- Say what you cut in the `note`.\n- Name the source file in `source`, so the reader can open the full record.\n\n## Sources, quotes, and conflicts\n\n- Rank `sources` by authority. When two sources disagree, the higher one wins and the text says so.\n- Quote a rule word for word, then cite its key: `\"quoted text\" {{spec §3.1.5}}`.\n- Declare every citation key in `quoteSources`. Map it to a vendored file, or to `null` when the source cannot be vendored.\n- Paraphrase sources with a `null` key, such as an SDK. Never quote them.\n- When sources disagree, quote both sides in the section, say which one the manual follows, and link the register entry.\n- Keep the register in the sources reference section. Give it five columns: id, sources, choice, sections, and upstream status.\n- Never name or cite another guide, course, or book. Cite specifications, source code, papers, and the subject's own documentation.\n\n## Prose limits\n\n| Limit | Value |\n|---|---|\n| words in a sentence | at most 25 |\n| words in a thesis | at most 30, one sentence |\n| words in a figure claim | at most 28, one sentence ending with a period |\n| words in a takeaway | at most 20, an instruction in imperative mood |\n| sentences in a paragraph | at most 6 |\n\nWrite 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.\n\nUse 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\u002Fprose-rules.md](references\u002Fprose-rules.md).\n\n## Figure must-haves\n\nUse the sibling `blueprint-figure` skill to draw the figures. Every figure in a manual must also meet these rules:\n\n- Use one of nine kinds: `sequence`, `structure`, `flow`, `comparison`, `timeline`, `tree`, `state`, `decision`, `layers`.\n- Show the real system: real ids, field names, method names, and sequence numbers from a capture.\n- Make one claim of at most 28 words. The caption says how to read the figure, then names its capture file.\n- Never draw generic boxes such as \"Component A\", stat cards, or progress bars.\n- Compare two behaviors of the subject. Never compare against an earlier build.\n- Give each hue one meaning per manual. `rose` is failure, `grey` is outside the subject, `amber` is lifecycle, `teal` is durable state.\n- Draw exchanges with the eight arrow styles below. Figure 0.1 teaches the ones the manual uses.\n- Use `viewBox=\"0 0 640 H\"` with H at most 760, text at least 11 units, and a file of at most 40 KB.\n- Put a `\u003Ctitle>` and a `\u003Cdesc>` of at least 40 characters on the root, which has `role=\"img\"`.\n- Start every `id` in the SVG with the figure id, because all figures share one page.\n- Write colours only as `var(--m-\u003Ctoken>, #hex)`, with the light value of the token as the hex.\n\n| Arrow style | Means |\n|---|---|\n| solid ink | a call or request |\n| dashed ink | a reply |\n| solid teal | a durable write |\n| dashed amber | a state change |\n| solid plum | a model call or compute |\n| dashed olive | an effect outside the system |\n| dotted indigo | a stream or an event |\n| dashed rose | a failure |\n\n## Build and audit\n\nInside the AI Engineering from Scratch repo, run these from the repository root:\n\n```bash\nnode --test site\u002Ftest_manuals.js\nnode site\u002Fbuild-manuals.js\nnode manuals\u002F_shared\u002Ffigkit.js build manuals\u002F\u003Cid>\nnode scripts\u002Faudit_manuals.js --manual \u003Cid>\n```\n\nOutside the repo, build your own audit from [references\u002Faudit.md](references\u002Faudit.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`.\n\n## Commit rules\n\n- Size commits by judgment. A section with its figures and the captures it adds is a good unit. A small fix across sections can be one commit.\n- Use the message `feat(manual\u002F\u003Cid>): \u003Csection slug>`.\n- Never commit generated output. Inside the repo, that is `site\u002Fmanual-\u003Cid>.html`, `site\u002Fmanuals.html`, and `site\u002Fmanuals-data.js`.\n- Keep `status` at `draft` until the manual is complete. A `ready` manual needs a `README.md`.\n- Update vendored sources only together with the `pin` in `manual.json`.\n\n## Check before you finish\n\n- [ ] `manual.json` validates, and `pin` has subject, version, source, commit, date, and verified.\n- [ ] Every section title names one thing that the specification defines.\n- [ ] Every section has a thesis, an outcome sentence in its first two paragraphs, one takeaways block, and a `Sources:` line.\n- [ ] Every `json`, `jsonl`, `http`, and `sse` block is a `listing` with a capture source.\n- [ ] The capture check runs offline and reports no drift.\n- [ ] Every quote of 24 or more characters is found word for word in its vendored file.\n- [ ] Every conflict has a register id, and each section that meets it links that id.\n- [ ] Every figure SVG is used by a document and matches its source script.\n- [ ] The audit prints `TOTAL 0`.\n- [ ] Commits are sized by judgment, with messages such as `feat(manual\u002F\u003Cid>): \u003Csection slug>`.\n\n## Files\n\n- [references\u002Fmanual-json.md](references\u002Fmanual-json.md): every field of `manual.json`, with a starter file.\n- [references\u002Fsection-template.md](references\u002Fsection-template.md): a section skeleton with each fence kind.\n- [references\u002Fresearch-and-sources.md](references\u002Fresearch-and-sources.md): the fact brief, vendoring, quotes, and the conflict register.\n- [references\u002Fcapture-kit.md](references\u002Fcapture-kit.md): how to record deterministic captures and check them for drift.\n- [references\u002Fprose-rules.md](references\u002Fprose-rules.md): the limits and the full banned word list.\n- [references\u002Faudit.md](references\u002Faudit.md): every audit rule, and how to reproduce the audit outside the repo.\n- Inside the AI Engineering from Scratch repo, also see `manuals\u002FAUTHORING.md`, `manuals\u002Fmanual.schema.json`, and `manuals\u002Fa2a-101\u002F`.\n",{"name":5,"tags":52,"version":53,"description":54},[31,46,30,32,43],"1.0.0","Writes a long technical manual that explains one subject at one pinned version, from its purpose to each request and response. Every listing comes from an offline capture, every claim traces to a ranked source, and an audit must report TOTAL 0. Use it for \"write a manual\", \"write a 101 manual for \u003Csubject>\", \"manual.json\", \"add a manual section\", \"build a capture kit\", \"audit the manual\", or \"pin a spec version and document it\".\n","main","fe6c657dfb8d02cc898fcee7d4cfbf663aae1416",".claude\u002Fskills\u002Fwrite-manual",13971,"https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch","https:\u002F\u002Faiengineeringfromscratch.com","https:\u002F\u002Fgithub.com\u002Frohitg00","Engineer | DevRel | GDE | CNCF, AAIF, Claude, Devin, PE Ambassador | Docker Captain | AWS CB | Ex - iii, Cloudera, Solo.io, Cerbos, Oracle, Reliance Jio","2026-11-11 20:45:16",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add rohitg00\u002Fai-engineering-from-scratch --skill write-manual",{"tool":70,"command":71},"bunx","bunx skills add rohitg00\u002Fai-engineering-from-scratch --skill write-manual",{"tool":73,"command":74},"pnpm","pnpm dlx skills add rohitg00\u002Fai-engineering-from-scratch --skill write-manual","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002FSKILL.md",true,[78,84,88,92,96,100],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Faudit.md","REFERENCE","参考文档",4322,"https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002Freferences\u002Faudit.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fcapture-kit.md",3417,"https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002Freferences\u002Fcapture-kit.md",{"path":89,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fmanual-json.md",6216,"https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002Freferences\u002Fmanual-json.md",{"path":93,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fprose-rules.md",3594,"https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002Freferences\u002Fprose-rules.md",{"path":97,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fresearch-and-sources.md",4926,"https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002Freferences\u002Fresearch-and-sources.md",{"path":101,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fsection-template.md",3759,"https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwrite-manual\u002Freferences\u002Fsection-template.md",[105,110,149,176,205,226],{"skillNo":106,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":47},"01M6ERNQB1QMAD1FH5Z5ASYHXZ","https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-manual\u002FSKILL.md",[],[19,21,20,32,35,34,46,43,44,33,22,40,39,37,41,38,36,31,30,42,45,29,23,25,28,26,27,24],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":129,"publishedAt":47},"01M6ERNKG9FZ3WGJ87B975SHW5","start-learning","One-time onboarding for the AI Engineering from Scratch curriculum (542 lessons, 20 phases). Interviews the learner, runs the placement quiz, and writes LEARNING.md, a persistent study plan the learn skill drives. Trigger phrases: \"start learning\", \"set up the course\", \"begin the curriculum\", \"onboard me\", \"create my learning plan\"","https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002Fskills\u002Fstart-learning\u002FSKILL.md",[116,121,126],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",{"categoryNo":127,"categoryName":128,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000039","教师与教育",[130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,27],"start","learning","start learning","SET","ai-engineering","time","up","learn","ai engineering","create","plan","me","course","learner","curriculum","study","trigger","interviews","my",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":47},"01M6ERNECV0WVSTXHX8KRF9MBJ","motion-figure","Builds figures that move or respond to the reader, in three tiers: SMIL animations and slider widgets inside lessons, interactive mechanism figures that show the named parts of a real system with a computed verdict, and ordered dither bands in the course palette. Triggers: \"animated figure\", \"add a slider widget\", \"interactive figure\", \"show how this system works\", \"make this diagram move\", \"dither masthead\", \"mechanism figure\", \"figure fence\".","https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002Fskills\u002Fmotion-figure\u002FSKILL.md",[],[156,157,158,159,160,161,162,163,164,165,33,166,167,142,168,169,170,171,172,173,174,175],"motion","motion figure","Animation","show","move","respond","palette","diagram","widgets","how","make","figures","SVG","three","system","triggers","interactive","with","animations","lessons",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":185,"publishedAt":47},"01M6ERNAC0DQ8ER3A99VQBXNNZ","mcpa-certification","AI-native tutor and onboarding workflow for the MCPA (Model Context Protocol Associate) certification in AI Engineering from Scratch. Use when a learner wants to prepare for the MCPA, resume their certification path, learn the next lesson interactively, run and verify practical labs, take the diagnostic or a full mock, or remediate weak exam domains from GitHub with Claude Code, Codex, ChatGPT, Cursor, or another agent.","https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002Fskills\u002Fmcpa-certification\u002FSKILL.md",[182,183,184],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},{"categoryNo":127,"categoryName":128,"taxonomyType":124,"taxonomyTypeDesc":125},[186,187,188,189,190,191,192,137,193,194,195,138,196,197,198,199,200,201,202,203,204],"mcpa certification","certification","lesson","practical","model","domains","exam","workflow","code","model context protocol","native","next","run","take","chatgpt","full","context","ai-native","when",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":212,"publishedAt":47},"01M6ERN5TAAAJ7FE9N86SX6M2M","lesson-screen","Opens a lesson screen in the browser next to the terminal while a course tutor teaches. It shows the lesson's registered figures, code traces with real values, and clickable predictions. It also builds a figure for the lesson on the fly with the course figure skills and any figure skill the host has installed: a blueprint, a mechanism, an isometric machine, or a 3D model. Clicks return to the tutor as events. Trigger phrases: \"open the lesson screen\", \"show me this visually\", \"show this in 3D\", \"draw the architecture\", \"visualize this lesson\", \"build a figure for this lesson\", \"lesson screen\".","https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002Fskills\u002Flesson-screen\u002FSKILL.md",[211],{"categoryNo":127,"categoryName":128,"taxonomyType":124,"taxonomyTypeDesc":125},[188,213,214,159,215,190,216,217,218,219,220,194,221,222,141,197,223,224,225,167],"screen","lesson screen","3D","open","host","Blueprint","predictions","show me","architecture","browser","terminal","fly","events",{"skillNo":227,"name":137,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":229,"categories":230,"keywords":234,"publishedAt":47},"01M6ERN1HS8HW1TRJVX5P7SPY0","Interactive lesson tutor for the AI Engineering from Scratch curriculum. Reads LEARNING.md, fetches the next lesson, teaches it section by section in the terminal, quizzes at the end, and records progress. Works cloned or entirely over raw.githubusercontent.com — no setup required. Trigger phrases: \"next lesson\", \"teach me\", \"continue the course\", \"let's learn\", \"resume learning\"","https:\u002F\u002Fgithub.com\u002Frohitg00\u002Fai-engineering-from-scratch\u002Fblob\u002Fmain\u002Fskills\u002Flearn\u002FSKILL.md",[231,232,233],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},{"categoryNo":127,"categoryName":128,"taxonomyType":124,"taxonomyTypeDesc":125},[137,188,134,235,138,141,236,197,223,142,144,146,237,238,131,172,239,240,28,27,24,241],"end","progress","records","continue","interactive-learning","From Scratch","scratch"]