[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KX34TP94HB6MHRFSHV2RGT":3,"skill-same:01M6KX34TP94HB6MHRFSHV2RGT":68},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M6KX34TP94HB6MHRFSHV2RGT","to-spec",null,"Turn the current conversation into a spec issue, without re-interviewing.","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\u002Fproject-management\u002Fto-spec\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"spec","to spec","git","gh issue","Bash","gh","grep","read","log","issue","conversation","git log","re","2026-11-10 10:12:30",false,"---\nname: to-spec\ndescription: Turn the current conversation into a spec issue, without re-interviewing.\nargument-hint: \"[parent issue]\"\nallowed-tools: Read, Grep, Glob, Bash(gh issue *), Bash(git log *)\n---\n\n# To Spec\n\nTurn the conversation and your understanding of the codebase into a spec, and\nfile it as an issue. Synthesize what you already know; the interview already\nhappened (usually through the grilling skill). Ask only when a gap would make\nthe spec wrong.\n\n## 1. Ground it in the code\n\nExplore the parts of the codebase the spec touches, if you haven't already.\nUse the project's terms from `GLOSSARY.md` throughout, and respect ADRs in the\narea. Done when you can name the modules the change touches.\n\n## 2. Agree the test seams\n\nSketch where the feature will be tested. Prefer existing seams to new ones,\nand the highest seam that reaches the behaviour: the fewer seams across the\ncodebase, the better, and one is ideal. Call the Skill tool with\n\"codebase-design\" if the shape of a module is in question. Done when the user\nhas confirmed the seams match their expectations.\n\n## 3. Write and file it\n\nFill the template below, then call the Skill tool with \"issue-create\" to file\nit (duplicate search, labels, preview). If the user named a parent issue,\nattach the new spec to it afterwards with\n`gh issue edit \u003Cparent> --add-sub-issue \u003Cspec>`. Done when the issue exists,\nis attached to any parent, and its URL is reported.\n\n```markdown\n## Problem\n\nThe problem, from the user's point of view.\n\n## Solution\n\nThe solution, from the user's point of view.\n\n## User stories\n\nA long, numbered list covering every aspect of the feature:\n\n1. As a \u003Cactor>, I want \u003Ccapability>, so that \u003Cbenefit>.\n\n## Implementation decisions\n\n- The modules built or changed, and the interfaces that change\n- Architectural decisions, schema changes, and API contracts\n- Technical clarifications from the conversation\n\nLeave out file paths and code: they go stale. The exception is a snippet a\nprototype produced that states a decision more precisely than prose (a state\nmachine, a type shape, a schema); trim it to the decision and note where it\ncame from.\n\n## Testing decisions\n\n- The agreed seams, and which modules are tested at each\n- What makes a good test here (external behaviour, not implementation)\n- Prior art: similar tests already in the codebase\n\n## Out of scope\n\nWhat this spec deliberately leaves out.\n\n## Further notes\n\nAnything else the implementer needs.\n```\n\nNext step: suggest the user run the to-tickets skill to split the spec into\ntickets.\n","# To Spec\n\nTurn the conversation and your understanding of the codebase into a spec, and\nfile it as an issue. Synthesize what you already know; the interview already\nhappened (usually through the grilling skill). Ask only when a gap would make\nthe spec wrong.\n\n## 1. Ground it in the code\n\nExplore the parts of the codebase the spec touches, if you haven't already.\nUse the project's terms from `GLOSSARY.md` throughout, and respect ADRs in the\narea. Done when you can name the modules the change touches.\n\n## 2. Agree the test seams\n\nSketch where the feature will be tested. Prefer existing seams to new ones,\nand the highest seam that reaches the behaviour: the fewer seams across the\ncodebase, the better, and one is ideal. Call the Skill tool with\n\"codebase-design\" if the shape of a module is in question. Done when the user\nhas confirmed the seams match their expectations.\n\n## 3. Write and file it\n\nFill the template below, then call the Skill tool with \"issue-create\" to file\nit (duplicate search, labels, preview). If the user named a parent issue,\nattach the new spec to it afterwards with\n`gh issue edit \u003Cparent> --add-sub-issue \u003Cspec>`. Done when the issue exists,\nis attached to any parent, and its URL is reported.\n\n```markdown\n## Problem\n\nThe problem, from the user's point of view.\n\n## Solution\n\nThe solution, from the user's point of view.\n\n## User stories\n\nA long, numbered list covering every aspect of the feature:\n\n1. As a \u003Cactor>, I want \u003Ccapability>, so that \u003Cbenefit>.\n\n## Implementation decisions\n\n- The modules built or changed, and the interfaces that change\n- Architectural decisions, schema changes, and API contracts\n- Technical clarifications from the conversation\n\nLeave out file paths and code: they go stale. The exception is a snippet a\nprototype produced that states a decision more precisely than prose (a state\nmachine, a type shape, a schema); trim it to the decision and note where it\ncame from.\n\n## Testing decisions\n\n- The agreed seams, and which modules are tested at each\n- What makes a good test here (external behaviour, not implementation)\n- Prior art: similar tests already in the codebase\n\n## Out of scope\n\nWhat this spec deliberately leaves out.\n\n## Further notes\n\nAnything else the implementer needs.\n```\n\nNext step: suggest the user run the to-tickets skill to split the spec into\ntickets.\n",{"name":5,"description":7,"allowed-tools":37,"argument-hint":38},"Read, Grep, Glob, Bash(gh issue *), Bash(git log *)","[parent issue]","main","023b01bfb4a86fbf1e38a749f1044cce3e5da67d","skills\u002Fproject-management\u002Fto-spec",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":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add dougborg\u002Fharness-kit --skill to-spec",{"tool":54,"command":55},"bunx","bunx skills add dougborg\u002Fharness-kit --skill to-spec",{"tool":57,"command":58},"pnpm","pnpm dlx skills add dougborg\u002Fharness-kit --skill to-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fproject-management\u002Fto-spec\u002FSKILL.md",true,[62],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"agents\u002Fopenai.yaml","REFERENCE","参考文档",144,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fproject-management\u002Fto-spec\u002Fagents\u002Fopenai.yaml",[69,88,108,141,165,181],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":32},"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",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[71,81,82,83,84,85,86,87],"lessons","you","with","learned","record","references","sessions",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":99,"publishedAt":32},"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",[94],{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[100,101,102,103,104,105,83,106,26,107],"logo","designer","svg logo designer","SVG","color","concepts","write","generate",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":120,"publishedAt":32},"01M6KX4BD3J9MZPPSH4MENH7FP","documentation-writer","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.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[114,117],{"categoryNo":115,"categoryName":116,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":118,"categoryName":119,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000036","内容创作者",[121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140],"writer","documentation writer","documentation","entries","changelog","architecture","document","files","use","question","README","notes","code","examples","pages","for","information","guides","type","writing",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":32},"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",[],[148,149,150,151,136,152,153,83,154,155,156,157,158,159,160,161,162,163,164,133],"adhd","mode","adhd mode","next","action","kit","output","style","progress","time","back","stop","session","reader","first","REST","harness",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":32},"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",[],[172,173,31,83,174,175,176,177,178,179,180],"wait","wait what","it","missing","message","context","explain","land","last",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":32},"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",[],[188,189,136,190,191,192,193,82,194,174,195,196],"to questionnaire","questionnaire","person","can","answer","meeting","make","async","decision"]