[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74FATJT7WZX5CSSG8RJDCF1":3,"skill-same:01M74FATJT7WZX5CSSG8RJDCF1":48},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":29,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M74FATJT7WZX5CSSG8RJDCF1","write-docs",null,"Collaborative authoring workflow for proposals, technical specs, decision docs, READMEs, ADRs, and long-form prose that must work for fresh readers. Three stages: gather context, iterate on structure, reader-test for a stranger. Use when asked to \"write the docs\", \"draft a proposal\", \"write a spec\", \"write an RFC\", \"write the README\", or when a doc must be understandable without this session's context.","open-gsd\u002Fgsd-pi","open-gsd","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F286935422?v=4","01M74F5F0MKW0B81YZHRVJMMWR","Open GSD","01M74F5F1782D325EYEM5GNXNC",1369,"MIT","https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fwrite-docs\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: write-docs\ndescription: >-\n  Collaborative authoring workflow for proposals, technical specs, decision docs, READMEs, ADRs, and long-form prose that must work for fresh readers. Three stages: gather context, iterate on structure, reader-test for a stranger. Use when asked to \"write the docs\", \"draft a proposal\", \"write a spec\", \"write an RFC\", \"write the README\", or when a doc must be understandable without this session's context.\n---\n\n\u003Cobjective>\nProduce documentation that works for a reader landing cold. Not a summary of what was built, not a dump of the conversation, but a document that transfers intent to someone who wasn't here. Run it through three stages — Context → Refine → Reader-Test — and don't ship until a hypothetical reader could act on it.\n\u003C\u002Fobjective>\n\n\u003Ccontext>\nGSD already produces durable artifacts (`M###-CONTEXT.md`, `S##-SUMMARY.md`, `DECISIONS.md`, `KNOWLEDGE.md`), but those are scaffolded by templates. This skill is for free-form documentation: README changes, public docs, architectural proposals, RFCs, PR descriptions, runbooks, and anything that lives under `docs\u002F`, `mintlify-docs\u002F`, or `gitbook\u002F` in this repo.\n\nInvocation points:\n\n- User asks to write or rewrite a piece of documentation\n- Before shipping a feature that adds user-facing behavior — docs need updates\n- After `write-milestone-brief` when the brief needs a public-facing summary for non-GSD consumers\n- PR description for a meaningful change\n\u003C\u002Fcontext>\n\n\u003Ccore_principle>\n**WRITE FOR THE FRESH READER.** The test is not \"does the maintainer understand it\" — you are the maintainer. The test is \"can someone who has never seen this code act correctly after reading this?\"\n\n**ITERATE STRUCTURE BEFORE PROSE.** An outline that's wrong will not be saved by good sentences. Agree on the sections, what each is for, and in what order before drafting the body.\n\n**NO FILE PATHS IN TRUNK DOCS.** Paths rot. Describe modules, behaviors, and invariants. A README that cites `src\u002Ffoo.ts:42` is a future broken link.\n\u003C\u002Fcore_principle>\n\n\u003Cprocess>\n\n## Stage 1: Context gathering\n\n1. **Who is the reader?** Internal engineer, open-source contributor, end user, future you at 3am. The answer changes everything.\n2. **What should they be able to do after reading?** Name the single post-read action. \"Understand the auth flow\" is not an action — \"implement a new auth provider using the documented extension points\" is.\n3. **What do they already know?** Assume they have docs for the language and framework, not for your codebase. Don't re-explain React; do explain your project's conventions.\n4. **What context from this conversation\u002Fcodebase belongs in the doc?** Ask the user to dump any missing material. Do not invent examples.\n\nOne round of clarifying questions. Then proceed.\n\n## Stage 2: Refine structure\n\n1. **Draft an outline, not prose.** Numbered sections, one-line purpose for each. Show it to the user.\n2. **Iterate the outline.** Remove sections the reader doesn't need. Reorder so the must-knows come first. Flag sections that can't be written without more input.\n3. **Only then, fill sections.** Write the body of each section in order. Keep sentences short. Prefer concrete examples over abstractions. Show small diffs or code snippets where they clarify; skip them where they'd rot.\n4. **Draft in place.** Write directly to the target file — `docs\u002F\u003Cname>.md`, `README.md`, `mintlify-docs\u002F…`. Do not keep a scratch draft in the conversation.\n\n## Stage 3: Reader-test\n\n1. **Cold-read it.** Read the doc top to bottom as if you hadn't written it. Stop at every moment you thought \"they already know X\" — that's a gap.\n2. **Can the named post-read action be taken?** Walk through it. If yes, the doc works. If no, identify the missing piece and add it.\n3. **Cut aggressively.** Anything that isn't serving the post-read action comes out. Documentation bloat kills docs.\n4. **Offer to the user:** \"Here's the draft. Want me to run a fresh sub-agent (`Agent(subagent_type=Explore)`) as a cold reader to stress-test it?\"\n\n## Stage 4: Wire it in\n\n1. Link to the new doc from relevant entry points (README.md index, docs\u002F sidebar, mintlify-docs config, etc.).\n2. If it documents a decision, also call `gsd_decision_save` with a one-line entry that points at the doc.\n3. If it's a public-facing change, flag for the next release notes \u002F CHANGELOG update.\n\n\u003C\u002Fprocess>\n\n\u003Canti_patterns>\n\n- **\"Writing a summary of what we did\"** — the reader doesn't care about the journey. Document the destination.\n- **Paths and line numbers in long-lived docs.** They rot. Use module names.\n- **Re-explaining general concepts.** If the reader needs to know what HTTP is, the doc is aimed at the wrong audience.\n- **Starting with prose.** Outline first, always.\n- **Not cold-reading.** Every doc gets one pass as if you've never seen it.\n- **Claiming \"done\" without the reader-test.** Docs that haven't been cold-read are notes, not docs.\n\n\u003C\u002Fanti_patterns>\n\n\u003Csuccess_criteria>\n\n- [ ] The reader and their post-read action are named explicitly.\n- [ ] The outline was agreed before prose was written.\n- [ ] A cold-read pass happened; gaps were closed.\n- [ ] No file paths or line numbers in the trunk doc (decision-scoped ADRs may include them).\n- [ ] Doc is linked from a relevant entry point — it is discoverable, not orphaned.\n- [ ] The named action is actually executable after reading.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\nProduce documentation that works for a reader landing cold. Not a summary of what was built, not a dump of the conversation, but a document that transfers intent to someone who wasn't here. Run it through three stages — Context → Refine → Reader-Test — and don't ship until a hypothetical reader could act on it.\n\u003C\u002Fobjective>\n\n\u003Ccontext>\nGSD already produces durable artifacts (`M###-CONTEXT.md`, `S##-SUMMARY.md`, `DECISIONS.md`, `KNOWLEDGE.md`), but those are scaffolded by templates. This skill is for free-form documentation: README changes, public docs, architectural proposals, RFCs, PR descriptions, runbooks, and anything that lives under `docs\u002F`, `mintlify-docs\u002F`, or `gitbook\u002F` in this repo.\n\nInvocation points:\n\n- User asks to write or rewrite a piece of documentation\n- Before shipping a feature that adds user-facing behavior — docs need updates\n- After `write-milestone-brief` when the brief needs a public-facing summary for non-GSD consumers\n- PR description for a meaningful change\n\u003C\u002Fcontext>\n\n\u003Ccore_principle>\n**WRITE FOR THE FRESH READER.** The test is not \"does the maintainer understand it\" — you are the maintainer. The test is \"can someone who has never seen this code act correctly after reading this?\"\n\n**ITERATE STRUCTURE BEFORE PROSE.** An outline that's wrong will not be saved by good sentences. Agree on the sections, what each is for, and in what order before drafting the body.\n\n**NO FILE PATHS IN TRUNK DOCS.** Paths rot. Describe modules, behaviors, and invariants. A README that cites `src\u002Ffoo.ts:42` is a future broken link.\n\u003C\u002Fcore_principle>\n\n\u003Cprocess>\n\n## Stage 1: Context gathering\n\n1. **Who is the reader?** Internal engineer, open-source contributor, end user, future you at 3am. The answer changes everything.\n2. **What should they be able to do after reading?** Name the single post-read action. \"Understand the auth flow\" is not an action — \"implement a new auth provider using the documented extension points\" is.\n3. **What do they already know?** Assume they have docs for the language and framework, not for your codebase. Don't re-explain React; do explain your project's conventions.\n4. **What context from this conversation\u002Fcodebase belongs in the doc?** Ask the user to dump any missing material. Do not invent examples.\n\nOne round of clarifying questions. Then proceed.\n\n## Stage 2: Refine structure\n\n1. **Draft an outline, not prose.** Numbered sections, one-line purpose for each. Show it to the user.\n2. **Iterate the outline.** Remove sections the reader doesn't need. Reorder so the must-knows come first. Flag sections that can't be written without more input.\n3. **Only then, fill sections.** Write the body of each section in order. Keep sentences short. Prefer concrete examples over abstractions. Show small diffs or code snippets where they clarify; skip them where they'd rot.\n4. **Draft in place.** Write directly to the target file — `docs\u002F\u003Cname>.md`, `README.md`, `mintlify-docs\u002F…`. Do not keep a scratch draft in the conversation.\n\n## Stage 3: Reader-test\n\n1. **Cold-read it.** Read the doc top to bottom as if you hadn't written it. Stop at every moment you thought \"they already know X\" — that's a gap.\n2. **Can the named post-read action be taken?** Walk through it. If yes, the doc works. If no, identify the missing piece and add it.\n3. **Cut aggressively.** Anything that isn't serving the post-read action comes out. Documentation bloat kills docs.\n4. **Offer to the user:** \"Here's the draft. Want me to run a fresh sub-agent (`Agent(subagent_type=Explore)`) as a cold reader to stress-test it?\"\n\n## Stage 4: Wire it in\n\n1. Link to the new doc from relevant entry points (README.md index, docs\u002F sidebar, mintlify-docs config, etc.).\n2. If it documents a decision, also call `gsd_decision_save` with a one-line entry that points at the doc.\n3. If it's a public-facing change, flag for the next release notes \u002F CHANGELOG update.\n\n\u003C\u002Fprocess>\n\n\u003Canti_patterns>\n\n- **\"Writing a summary of what we did\"** — the reader doesn't care about the journey. Document the destination.\n- **Paths and line numbers in long-lived docs.** They rot. Use module names.\n- **Re-explaining general concepts.** If the reader needs to know what HTTP is, the doc is aimed at the wrong audience.\n- **Starting with prose.** Outline first, always.\n- **Not cold-reading.** Every doc gets one pass as if you've never seen it.\n- **Claiming \"done\" without the reader-test.** Docs that haven't been cold-read are notes, not docs.\n\n\u003C\u002Fanti_patterns>\n\n\u003Csuccess_criteria>\n\n- [ ] The reader and their post-read action are named explicitly.\n- [ ] The outline was agreed before prose was written.\n- [ ] A cold-read pass happened; gaps were closed.\n- [ ] No file paths or line numbers in the trunk doc (decision-scoped ADRs may include them).\n- [ ] Doc is linked from a relevant entry point — it is discoverable, not orphaned.\n- [ ] The named action is actually executable after reading.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7},"main","c0bc9c4e7e0a8581aeac3af397031dc3a63d012e","src\u002Fresources\u002Fskills\u002Fwrite-docs",118,"https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi","https:\u002F\u002Fwww.opengsd.net","https:\u002F\u002Fgithub.com\u002Fopen-gsd","opengsd.net","Most AI coding setups rot as the context window fills. Open GSD keeps the context clean, the work verified, and the git history honest — ship more, worry less.","2026-11-15 00:38:19",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add open-gsd\u002Fgsd-pi --skill write-docs",{"tool":40,"command":41},"bunx","bunx skills add open-gsd\u002Fgsd-pi --skill write-docs",{"tool":43,"command":44},"pnpm","pnpm dlx skills add open-gsd\u002Fgsd-pi --skill write-docs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fwrite-docs\u002FSKILL.md",true,[],[49,56,63,70,77,84],{"skillNo":50,"name":51,"nameZh":6,"description":52,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":19},"01M74FAXPHS0QT1S067QDKYDBX","write-milestone-brief","Synthesize the current conversation into a milestone brief (PRD). Saves it as the milestone CONTEXT (`gsd_summary_save`) by default, or files a GitHub issue only with explicit user confirmation. Use when asked to \"turn this into a PRD\", \"draft a milestone brief\", \"capture this context\", \"write it up\", or when enough has been discussed to commit the plan to paper. Does not interview — it synthesizes what is already known.","https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fwrite-milestone-brief\u002FSKILL.md",[],[],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M74FAQ8HKNVGCZ5ZBHW03A76","web-quality-audit","Comprehensive web quality audit covering performance, accessibility, SEO, and best practices. Use when asked to \"audit my site\", \"review web quality\", \"run lighthouse audit\", \"check page quality\", or \"optimize my website\".","https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fweb-quality-audit\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M74FAMZ7WP4RPAG20F448MVF","web-design-guidelines","Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".","https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fweb-design-guidelines\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M74FAHYM672GKGGS8KMY9CKC","verify-before-complete","Block completion claims until verification evidence has been produced in the current message. Use before marking a task\u002Fslice\u002Fmilestone complete, before creating a commit or PR, before saying \"it works\" or \"tests pass\", and any time you are about to claim work is done. The rule is: evidence before claims, always — running the verification must happen now, not \"earlier in the session\". Fresh output or no claim.","https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fverify-before-complete\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M74FADG78GX090P4YE5ZHR2A","userinterface-wiki","UI\u002FUX best practices for web interfaces. Use when reviewing animations, CSS, audio, typography, UX patterns, prefetching, or icon implementations. Covers 11 categories from animation principles to typography. Outputs file:line findings.","https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Fuserinterface-wiki\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M74FAB75D1RJDGWAETQ9JB4G","test","Generate or run tests. Auto-detects test framework, generates comprehensive tests for source files, or runs existing test suites with failure analysis.","https:\u002F\u002Fgithub.com\u002Fopen-gsd\u002Fgsd-pi\u002Fblob\u002Fmain\u002Fsrc\u002Fresources\u002Fskills\u002Ftest\u002FSKILL.md",[],[]]