[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KWYFSHA7VZSD3FPTMYQS9P":3,"skill-same:01M6KWYFSHA7VZSD3FPTMYQS9P":69},{"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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":62},"01M6KWYFSHA7VZSD3FPTMYQS9P","to-tickets",null,"Split a spec into tracer-bullet sub-issues with blocking links.","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\u002Fclaude-skills\u002Fto-tickets\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"to tickets","tickets","spec","issues","gh issue","Bash","gh","grep","read","issue","with","links","split","true","2026-11-10 10:12:30",false,"---\nname: to-tickets\ndescription: Split a spec into tracer-bullet sub-issues with blocking links.\nargument-hint: \"[spec issue]\"\nallowed-tools: Read, Grep, Glob, Bash(gh issue *), Bash(gh label *), Bash(${CLAUDE_SKILL_DIR}\u002Fsub-issue-frontier.sh*)\ndisable-model-invocation: true\n---\n\n# To Tickets\n\nBreak the work into **tickets**: thin **tracer-bullet** slices, each cutting\nend to end through every layer it needs, each declaring the tickets that\n**block** it.\n\n## 1. Gather context\n\nWork from the conversation. If the user passed a spec issue, read its body and\ncomments (`gh issue view \u003Cn> --comments`). Explore the codebase if you haven't,\nand use the project's `GLOSSARY.md` terms in every title. Look for\n**prefactoring** that makes the work easier: make the change easy, then make\nthe easy change. Done when you know which modules the work touches.\n\n## 2. Draft the slices\n\nEach ticket:\n\n- cuts a narrow but complete path through every layer (schema, API, UI,\n  tests), never one horizontal layer;\n- is demoable or verifiable on its own;\n- fits in one fresh agent session;\n- lists the tickets that must finish before it can start. Prefactoring comes\n  first.\n\n**Wide refactors are the exception.** A mechanical change whose blast radius\nfans across the codebase (renaming a column, retyping a shared symbol) can't\nland green as one slice. Sequence it as **expand-contract**: first add the new\nform beside the old; then migrate callers in batches sized by blast radius\n(per package or directory), each batch its own ticket blocked by the expand;\nthen delete the old form in a ticket blocked by every batch. When even a batch\ncan't stay green alone, let the batches share an integration branch that\nblocks a final integrate-and-verify ticket.\n\nDone when every slice has a title, its blockers, and the end-to-end behaviour\nit delivers, and each fits one session.\n\n## 3. Check the breakdown with the user\n\nShow a numbered list: each ticket's title, what blocks it, and the end-to-end\nbehaviour it delivers. Ask whether the granularity is right, whether each\nblocking edge is real, and what to merge or split. Ask as the grilling skill\ndoes (`AskUserQuestion` on Claude Code). Done when the user approves the\nbreakdown.\n\n## 4. File them\n\nFile in dependency order, blockers first, so each ticket can reference real\nissue numbers. With a spec issue, make each ticket its sub-issue and use\nGitHub's native blocking links:\n\n```bash\ngh issue create --title \"\u003Ctitle>\" --parent \u003Cspec> --blocked-by \u003Cn>,\u003Cn> \\\n  --body-file - \u003C\u003C'EOF'\n\u003Cticket body>\nEOF\n```\n\nWithout a spec issue, drop `--parent`. `--parent` and `--blocked-by` need\n`gh` 2.94 or later; with an older `gh`, put `Part of #\u003Cspec>` and\n`Blocked by: #\u003Cn>, #\u003Cn>` at the top of each body instead. Apply the repo's existing labels\n(`gh label list`); leave the spec issue itself unchanged.\n\n```markdown\n## What to build\n\nThe end-to-end behaviour this ticket makes work, from the user's point of\nview, not a layer-by-layer list.\n\n## Acceptance criteria\n\n- [ ] Criterion 1\n- [ ] Criterion 2\n```\n\nLeave out file paths and code, as in the spec, except a decision-bearing\nsnippet from a prototype.\n\nDone when every approved ticket is filed with its parent and blocking links,\nand you've reported the **frontier**: the tickets with no open blockers, ready\nto start now (`${CLAUDE_SKILL_DIR}\u002Fsub-issue-frontier.sh \u003Cspec>`).\n\nNext step: suggest the user run the implement skill for one ticket at a time,\nor the implement-spec skill to build the whole graph in parallel.\n","# To Tickets\n\nBreak the work into **tickets**: thin **tracer-bullet** slices, each cutting\nend to end through every layer it needs, each declaring the tickets that\n**block** it.\n\n## 1. Gather context\n\nWork from the conversation. If the user passed a spec issue, read its body and\ncomments (`gh issue view \u003Cn> --comments`). Explore the codebase if you haven't,\nand use the project's `GLOSSARY.md` terms in every title. Look for\n**prefactoring** that makes the work easier: make the change easy, then make\nthe easy change. Done when you know which modules the work touches.\n\n## 2. Draft the slices\n\nEach ticket:\n\n- cuts a narrow but complete path through every layer (schema, API, UI,\n  tests), never one horizontal layer;\n- is demoable or verifiable on its own;\n- fits in one fresh agent session;\n- lists the tickets that must finish before it can start. Prefactoring comes\n  first.\n\n**Wide refactors are the exception.** A mechanical change whose blast radius\nfans across the codebase (renaming a column, retyping a shared symbol) can't\nland green as one slice. Sequence it as **expand-contract**: first add the new\nform beside the old; then migrate callers in batches sized by blast radius\n(per package or directory), each batch its own ticket blocked by the expand;\nthen delete the old form in a ticket blocked by every batch. When even a batch\ncan't stay green alone, let the batches share an integration branch that\nblocks a final integrate-and-verify ticket.\n\nDone when every slice has a title, its blockers, and the end-to-end behaviour\nit delivers, and each fits one session.\n\n## 3. Check the breakdown with the user\n\nShow a numbered list: each ticket's title, what blocks it, and the end-to-end\nbehaviour it delivers. Ask whether the granularity is right, whether each\nblocking edge is real, and what to merge or split. Ask as the grilling skill\ndoes (`AskUserQuestion` on Claude Code). Done when the user approves the\nbreakdown.\n\n## 4. File them\n\nFile in dependency order, blockers first, so each ticket can reference real\nissue numbers. With a spec issue, make each ticket its sub-issue and use\nGitHub's native blocking links:\n\n```bash\ngh issue create --title \"\u003Ctitle>\" --parent \u003Cspec> --blocked-by \u003Cn>,\u003Cn> \\\n  --body-file - \u003C\u003C'EOF'\n\u003Cticket body>\nEOF\n```\n\nWithout a spec issue, drop `--parent`. `--parent` and `--blocked-by` need\n`gh` 2.94 or later; with an older `gh`, put `Part of #\u003Cspec>` and\n`Blocked by: #\u003Cn>, #\u003Cn>` at the top of each body instead. Apply the repo's existing labels\n(`gh label list`); leave the spec issue itself unchanged.\n\n```markdown\n## What to build\n\nThe end-to-end behaviour this ticket makes work, from the user's point of\nview, not a layer-by-layer list.\n\n## Acceptance criteria\n\n- [ ] Criterion 1\n- [ ] Criterion 2\n```\n\nLeave out file paths and code, as in the spec, except a decision-bearing\nsnippet from a prototype.\n\nDone when every approved ticket is filed with its parent and blocking links,\nand you've reported the **frontier**: the tickets with no open blockers, ready\nto start now (`${CLAUDE_SKILL_DIR}\u002Fsub-issue-frontier.sh \u003Cspec>`).\n\nNext step: suggest the user run the implement skill for one ticket at a time,\nor the implement-spec skill to build the whole graph in parallel.\n",{"name":5,"description":7,"allowed-tools":38,"argument-hint":39,"disable-model-invocation":40},"Read, Grep, Glob, Bash(gh issue *), Bash(gh label *), Bash(${CLAUDE_SKILL_DIR}\u002Fsub-issue-frontier.sh*)","[spec issue]",true,"main","023b01bfb4a86fbf1e38a749f1044cce3e5da67d","claude-skills\u002Fto-tickets",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":51,"prompt":61,"zipAvailable":40},[52,55,58],{"tool":53,"command":54},"npx","npx skills add dougborg\u002Fharness-kit --skill to-tickets",{"tool":56,"command":57},"bunx","bunx skills add dougborg\u002Fharness-kit --skill to-tickets",{"tool":59,"command":60},"pnpm","pnpm dlx skills add dougborg\u002Fharness-kit --skill to-tickets","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fto-tickets\u002FSKILL.md",[63],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"sub-issue-frontier.sh","SCRIPT","脚本",2253,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fclaude-skills\u002Fto-tickets\u002Fsub-issue-frontier.sh",[70,88,108,141,165,182],{"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":81,"publishedAt":33},"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",[76],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[72,82,83,29,84,85,86,87],"lessons","you","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":33},"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,29,106,27,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":33},"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":79,"taxonomyTypeDesc":80},"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":33},"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,29,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":33},"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,174,29,175,176,177,178,179,180,181],"wait","wait what","re","it","missing","message","context","explain","land","last",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":33},"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",[],[189,190,136,191,192,193,194,83,195,175,196,197],"to questionnaire","questionnaire","person","can","answer","meeting","make","async","decision"]