[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KX4BD3J9MZPPSH4MENH7FP":3,"skill-same:01M6KX4BD3J9MZPPSH4MENH7FP":84},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6KX4BD3J9MZPPSH4MENH7FP","documentation-writer",null,"Writes and revises human-facing documentation — READMEs, contributor and setup guides, reference pages, architecture notes, CLAUDE.md, and changelog entries. Covers picking the right document type for the question being asked, structuring for skimming, writing examples that actually run, and keeping docs from going stale. Use when creating or rewriting docs, when a README has drifted from the code, or when deciding where a piece of information belongs. For SKILL.md and agent files, use \u002Fskill-writer instead.","dougborg\u002Fharness-kit","dougborg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1261222?v=4","01M6KWS4PB51EYD4ZDJJSGNGB2","Doug Borg","01M6KWS4T8ZZW6SX5QZS9B5BN2",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"documentation","documentation writer","writer","use","for","information","guides","type","pages","entries","document","files","writing","question","README","examples","changelog","code","notes","architecture","2026-11-10 10:12:30",false,"---\nname: documentation-writer\ndescription: >-\n  Writes and revises human-facing documentation — READMEs, contributor and\n  setup guides, reference pages, architecture notes, CLAUDE.md, and changelog\n  entries. Covers picking the right document type for the question being\n  asked, structuring for skimming, writing examples that actually run, and\n  keeping docs from going stale. Use when creating or rewriting docs, when a\n  README has drifted from the code, or when deciding where a piece of\n  information belongs. For SKILL.md and agent files, use \u002Fskill-writer instead.\nallowed-tools: Read, Write, Edit, Glob, Grep\n---\n\n# \u002Fdocumentation-writer — Human-Facing Documentation\n\nDocumentation fails in two directions: it does not answer the question the\nreader arrived with, or it answers it somewhere the reader never looks. Most of\nthe work is deciding what kind of document you are writing and who is reading\nit, before writing a line.\n\n## Identify the document before writing it\n\nReaders arrive with one of four questions. Mixing the answers into one page is\nthe most common documentation failure — a tutorial interrupted by API tables\nserves neither reader.\n\n| Reader's question | Document type | Shape |\n| --- | --- | --- |\n| \"Get me to a first success\" | Tutorial \u002F quickstart | Ordered steps, one path, no options |\n| \"How do I accomplish X?\" | How-to guide | Task-titled, assumes basics, may branch |\n| \"What are the exact parameters?\" | Reference | Complete, structured, alphabetical or grouped |\n| \"Why is it built this way?\" | Explanation \u002F ADR | Prose, trade-offs, alternatives rejected |\n\nIf a page is trying to be two of these, split it and cross-link.\n\n## Write for scanning\n\nReaders scan before they read. Every structural choice should reward a reader\nwho only looks at headings and the first line of each section.\n\n- **Headings state the answer, not the topic.** \"Run migrations before starting\n  the server\" beats \"Migrations.\"\n- **Front-load.** The first sentence of a section carries its conclusion; the\n  rest supports it.\n- **One idea per paragraph**, and prefer a table or list when the content is\n  genuinely parallel — but not when it is prose wearing a list costume.\n- **Link out instead of inlining depth.** Name what is on the other side of the\n  link so the reader can judge whether to follow it.\n\nLength follows the content. A README for a small tool may be thirty lines; a\nreference page may be five hundred. There is no target word count — the test is\nwhether a reader can find their answer, not how long the page is.\n\n## Examples must run\n\nCopy-pasteable examples are the highest-value content in most documentation,\nand wrong ones are the highest-cost.\n\n- Show real commands and real output, not placeholders the reader must decode.\n- Verify examples against the current code before publishing. If you cannot run\n  it, say what version it was checked against.\n- Prefer a complete small example over a fragment with elisions.\n- Include the failure case when it is common — the error message a reader will\n  paste into a search box is worth documenting verbatim.\n\n## Put information where it will be found\n\nThe right location beats the right words. Before writing, check whether the\ninformation already lives somewhere and is simply stale.\n\n- **README** — what this is, who it is for, how to run it, where to go next.\n  Not a manual.\n- **Code comments** — why this line is surprising. Never what the line does.\n- **`CLAUDE.md`** — the conventions an agent must hold to work in this repo.\n  Keep it short; it loads on every session.\n- **Reference docs next to the code they describe**, so a change and its\n  documentation land in the same diff.\n- **Changelog \u002F release notes** — what changed for a consumer, in their terms,\n  not commit subjects.\n\nDuplicating content across locations guarantees divergence. Pick one home and\nlink to it.\n\n## Keep it from rotting\n\nStale documentation is worse than none, because readers trust it.\n\n- Avoid time-relative phrasing — \"currently\", \"new\", \"recently\", \"for now\",\n  \"the upcoming release\". Write what is true, or date the claim.\n- Do not document unreleased or intended behavior as if it exists.\n- When you change behavior, grep for the old behavior in the docs in the same\n  change.\n- Prefer generated reference material (CLI `--help`, schema dumps) over\n  hand-maintained tables that will drift.\n- If you find documentation that is wrong, fix it or delete it. Leaving it with\n  a caveat is the worst of the three options.\n\n## Voice\n\n- Second person and active voice: \"run the migration\", not \"the migration\n  should be run.\"\n- Present tense for behavior: \"the hook blocks the commit.\"\n- Define a term once, then use exactly that term — synonyms read as new\n  concepts.\n- Say what a thing does before saying what it is called.\n- Cut hedges (\"simply\", \"just\", \"of course\", \"obviously\"). They add nothing and\n  make a stuck reader feel worse.\n\n## Before you ship\n\n- Does the first paragraph tell a stranger whether this page is for them?\n- Can a reader who skims only the headings get the gist?\n- Does every command and code block run as written?\n- Is anything here duplicated from another document?\n- Would this still be correct in six months, or does it need a date?\n\n## Related\n\n- `\u002Fskill-writer` — SKILL.md and agent files, which have different constraints\n  (they load into a model's context and carry frontmatter contracts)\n- `CLAUDE.md` — this project's own conventions\n","# \u002Fdocumentation-writer — Human-Facing Documentation\n\nDocumentation fails in two directions: it does not answer the question the\nreader arrived with, or it answers it somewhere the reader never looks. Most of\nthe work is deciding what kind of document you are writing and who is reading\nit, before writing a line.\n\n## Identify the document before writing it\n\nReaders arrive with one of four questions. Mixing the answers into one page is\nthe most common documentation failure — a tutorial interrupted by API tables\nserves neither reader.\n\n| Reader's question | Document type | Shape |\n| --- | --- | --- |\n| \"Get me to a first success\" | Tutorial \u002F quickstart | Ordered steps, one path, no options |\n| \"How do I accomplish X?\" | How-to guide | Task-titled, assumes basics, may branch |\n| \"What are the exact parameters?\" | Reference | Complete, structured, alphabetical or grouped |\n| \"Why is it built this way?\" | Explanation \u002F ADR | Prose, trade-offs, alternatives rejected |\n\nIf a page is trying to be two of these, split it and cross-link.\n\n## Write for scanning\n\nReaders scan before they read. Every structural choice should reward a reader\nwho only looks at headings and the first line of each section.\n\n- **Headings state the answer, not the topic.** \"Run migrations before starting\n  the server\" beats \"Migrations.\"\n- **Front-load.** The first sentence of a section carries its conclusion; the\n  rest supports it.\n- **One idea per paragraph**, and prefer a table or list when the content is\n  genuinely parallel — but not when it is prose wearing a list costume.\n- **Link out instead of inlining depth.** Name what is on the other side of the\n  link so the reader can judge whether to follow it.\n\nLength follows the content. A README for a small tool may be thirty lines; a\nreference page may be five hundred. There is no target word count — the test is\nwhether a reader can find their answer, not how long the page is.\n\n## Examples must run\n\nCopy-pasteable examples are the highest-value content in most documentation,\nand wrong ones are the highest-cost.\n\n- Show real commands and real output, not placeholders the reader must decode.\n- Verify examples against the current code before publishing. If you cannot run\n  it, say what version it was checked against.\n- Prefer a complete small example over a fragment with elisions.\n- Include the failure case when it is common — the error message a reader will\n  paste into a search box is worth documenting verbatim.\n\n## Put information where it will be found\n\nThe right location beats the right words. Before writing, check whether the\ninformation already lives somewhere and is simply stale.\n\n- **README** — what this is, who it is for, how to run it, where to go next.\n  Not a manual.\n- **Code comments** — why this line is surprising. Never what the line does.\n- **`CLAUDE.md`** — the conventions an agent must hold to work in this repo.\n  Keep it short; it loads on every session.\n- **Reference docs next to the code they describe**, so a change and its\n  documentation land in the same diff.\n- **Changelog \u002F release notes** — what changed for a consumer, in their terms,\n  not commit subjects.\n\nDuplicating content across locations guarantees divergence. Pick one home and\nlink to it.\n\n## Keep it from rotting\n\nStale documentation is worse than none, because readers trust it.\n\n- Avoid time-relative phrasing — \"currently\", \"new\", \"recently\", \"for now\",\n  \"the upcoming release\". Write what is true, or date the claim.\n- Do not document unreleased or intended behavior as if it exists.\n- When you change behavior, grep for the old behavior in the docs in the same\n  change.\n- Prefer generated reference material (CLI `--help`, schema dumps) over\n  hand-maintained tables that will drift.\n- If you find documentation that is wrong, fix it or delete it. Leaving it with\n  a caveat is the worst of the three options.\n\n## Voice\n\n- Second person and active voice: \"run the migration\", not \"the migration\n  should be run.\"\n- Present tense for behavior: \"the hook blocks the commit.\"\n- Define a term once, then use exactly that term — synonyms read as new\n  concepts.\n- Say what a thing does before saying what it is called.\n- Cut hedges (\"simply\", \"just\", \"of course\", \"obviously\"). They add nothing and\n  make a stuck reader feel worse.\n\n## Before you ship\n\n- Does the first paragraph tell a stranger whether this page is for them?\n- Can a reader who skims only the headings get the gist?\n- Does every command and code block run as written?\n- Is anything here duplicated from another document?\n- Would this still be correct in six months, or does it need a date?\n\n## Related\n\n- `\u002Fskill-writer` — SKILL.md and agent files, which have different constraints\n  (they load into a model's context and carry frontmatter contracts)\n- `CLAUDE.md` — this project's own conventions\n",{"name":5,"description":7,"allowed-tools":54},"Read, Write, Edit, Glob, Grep","main","023b01bfb4a86fbf1e38a749f1044cce3e5da67d","skills\u002Fwriting\u002Fdocumentation-writer",1,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit","https:\u002F\u002Fgithub.com\u002Fdougborg","http:\u002F\u002Fdougborg.org","Platforms and Infrastructure Software Engineer","2026-10-19 05:43:53",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add dougborg\u002Fharness-kit --skill documentation-writer",{"tool":70,"command":71},"bunx","bunx skills add dougborg\u002Fharness-kit --skill documentation-writer",{"tool":73,"command":74},"pnpm","pnpm dlx skills add dougborg\u002Fharness-kit --skill documentation-writer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",true,[78],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"agents\u002Fopenai.yaml","REFERENCE","参考文档",118,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002Fagents\u002Fopenai.yaml",[85,102,121,145,162,178],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":94,"publishedAt":49},"01M6KX4J65S5FZKMSN5DQNPSZM","teach","Teach yourself a topic over several sessions, with lessons, references, and a record of what you've learned.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fteach\u002FSKILL.md",[91],{"categoryNo":92,"categoryName":93,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000039","教师与教育",[87,95,96,97,98,99,100,101],"lessons","you","with","learned","record","references","sessions",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":111,"publishedAt":49},"01M6KX4FSSG7MHF00JDT5QT0BQ","svg-logo-designer","Generate SVG logos with multiple concepts, layouts, and color variations.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fsvg-logo-designer\u002FSKILL.md",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[112,113,114,115,97,116,117,118,119,120],"logo","designer","svg logo designer","SVG","concepts","color","write","read","generate",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":49},"01M6KX47ZJ4ZWHDN3MY8SYAWZZ","adhd-mode","Shapes every response for a reader with ADHD: the next action first, numbered steps, progress restated each turn, tangents held back, concrete time estimates, wins made visible. Stays on for the rest of the session until the reader says \"stop adhd mode\". On Claude Code, the harness-kit:adhd output style does the same without invoking this skill.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fadhd-mode\u002FSKILL.md",[],[128,129,130,131,132,133,134,135,136,33,137,138,139,140,141,142,97,143,144,46],"mode","adhd","adhd mode","progress","time","back","style","output","next","stop","session","reader","first","REST","harness","action","kit",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":49},"01M6KX463Z6E18EPDW873GDHKB","wait-what","That last message didn't land: re-explain it with the missing context.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fwait-what\u002FSKILL.md",[],[152,153,97,154,155,156,157,158,159,160,161],"wait","wait what","last","re","it","missing","message","context","explain","land",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":49},"01M6KX43NE1NB0Y2HECY515730","to-questionnaire","Turn a decision you can't make alone into a questionnaire for the one person who can answer it, filled in async or together in a meeting.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fto-questionnaire\u002FSKILL.md",[],[169,170,33,171,172,173,174,96,175,156,176,177],"questionnaire","to questionnaire","person","can","answer","meeting","make","async","decision",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":187,"publishedAt":49},"01M6KX409ND71TZNSGS5QMKX3F","research","Investigates a question against primary sources (official docs, source code, specs, first-party APIs) and writes the findings, with a citation for every claim, to a Markdown file. Use when the user wants a topic researched or facts gathered from documentation, when a decision waits on facts from outside the repo, and when reading legwork should run while other work continues.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fresearch\u002FSKILL.md",[184],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[180,188,33,189,190,97,191,192,32,42,193,194,177,195,140,196,46,197,29,198],"work","facts","reading","sources","claim","repo","party","markdown","file","run","official"]