[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H87SQHTYJGP904Y5NJD2SP":3,"skill-same:01M6H87SQHTYJGP904Y5NJD2SP":72},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":65},"01M6H87SQHTYJGP904Y5NJD2SP","sweep",null,"Turn a pile of small fixes into a batch \u002Ffleet can dispatch. Takes the open `inbox` issues and any items pasted with the command, explores them in one pass, rejects anything too big for a small fix and takes it out of the inbox, merges items that touch the same files into one ticket, and files the tickets under one dated `sweep-YYYY-MM-DD` label. Use for \"sweep the inbox\", \"batch these fixes\", \"turn these into tickets and fleet them\". For one ad-hoc ticket, use file-issue; for a feature, use \u002Fto-tickets.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fsweep\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"files","fixes","for","can","true","with","mm","touch","ticket","feature","inbox","dispatch","use","fix","command","open","file","batch","issues","2026-11-10 10:12:30",false,"---\nname: sweep\ndescription: >\n  Turn a pile of small fixes into a batch \u002Ffleet can dispatch. Takes the open `inbox` issues and\n  any items pasted with the command, explores them in one pass, rejects anything too big for a\n  small fix and takes it out of the inbox, merges items that touch the same files into one\n  ticket, and files the tickets under one dated `sweep-YYYY-MM-DD` label. Use for \"sweep the\n  inbox\", \"batch these fixes\", \"turn these into tickets and fleet them\". For one ad-hoc ticket,\n  use file-issue; for a feature, use \u002Fto-tickets.\ndisable-model-invocation: true\n---\n\n# Sweep\n\nSmall fixes cost little to make and a lot to run one at a time. Sweep pays the exploration and\nreview once for the whole batch: the label it files under is a feature label as far as\n`\u002Ffleet` is concerned, so dispatch, integration and the single PR into `main` all apply.\n\n## 1. Gather\n\n- `gh issue list --state open --label inbox --json number,title,body`\n- Any items in the user's message, split into one item per distinct fix.\n\nNothing from either source: say the inbox is empty and stop.\n\n## 2. Explore once\n\nLocate every item in a single pass, never one per item. With a `.codegraph\u002F` index, one\n`codegraph_explore` naming every item's symbols and files. Otherwise one `Explore` subagent with\n`model: \"haiku\"`, given the whole list, returning per item: the files and symbols involved, and a\nrough size (lines, files).\n\n## 3. Reject what isn't small\n\nAn item stays in the sweep only if all hold:\n\n- it changes existing behaviour or code, not a new feature;\n- about 80 lines or fewer, across 1–3 files;\n- no schema, public API or dependency change;\n- the cause is known. A bug whose cause still needs finding is triage, not a sweep item.\n\nRejects are listed with their route: `triage-issue` for an unexplained bug, `capture-idea` or\n`to-prd` for a feature, and `needs-design` for a design or refactor concern with no known fix\n(such as a `REFLECT later:` marker). Name no skill for `needs-design`: deciding the fix is the\nopen work. A rejected inbox issue stays open but leaves the inbox in step 6, or every later\nsweep explores and rejects it again.\n\n## 4. Cluster by file\n\nItems that touch a common file go into one ticket, transitively: if A shares a file with B and B\nwith C, all three are one ticket. Disjoint items stay separate tickets, so they run in parallel\nwithout conflicting.\n\nIf a cluster grows past about 3 files or 150 lines, split it back into tickets and chain them\nwith `## Blocked by` in item order, so `\u002Ffleet` runs them in successive waves instead of\ncolliding.\n\nSize each ticket: `size:xs` when it touches one file and needs at most one new test case,\notherwise `size:s`.\n\n## 5. Confirm the batch\n\nShow one table and wait for a yes. The clustering is the decision, so this is the one confirm:\n\n```\nLabel: sweep-2026-10-07\n| Ticket | Items (inbox #) | Files | Size |\nRejected: \u003Citem> (inbox #) → \u003Croute>\n```\n\n## 6. File\n\nLabel: `sweep-YYYY-MM-DD` with today's date. If that label already has open issues, append\n`-2`, `-3`, … so a dispatched batch never gains tickets mid-flight. Create the label with\n`gh label create \"\u003Clabel>\" -d \"Sweep of small fixes\"`, and `size:xs` \u002F `size:s` if missing.\n\nEach ticket uses file-issue's body (`## Context`, `## Where to look`, `## Acceptance criteria`)\nwith step 2's findings as \"Where to look\", plus:\n\n```markdown\n## Items\n\n- \u003Citem> (from #\u003Cinbox issue>)\n\n## Blocked by\n\nNone\n```\n\nAcceptance criteria: one or two per item.\n\n```bash\ngh issue create --title \"\u003Ctitle>\" --body-file \u003Ctmpfile> \\\n  --label \"\u003Csweep label>\" --label \"status:ready\" --label \"size:\u003Cxs|s>\"\n```\n\nA chained ticket from step 4 gets `status:backlog` and a `- Blocked by #\u003CN>` line instead.\nThen close every absorbed inbox issue: `gh issue close \u003CN> --comment \"Swept into #\u003Cticket>\"`.\n\nTake every reject that came from an inbox issue out of the inbox with\n`gh issue edit \u003CN> --remove-label inbox`. A `needs-design` reject also gets\n`--add-label needs-design`; create that label first if missing:\n`gh label create needs-design -d \"Needs a design decision before it can be fixed\"`.\n\n## 7. Report\n\nThe tickets as `#\u003CN> \u003Ctitle> (size)`, one per line, then the rejects with their route, then the\ncommand on its own line:\n\n```\n\u002Ffleet dispatch \u003Csweep label>\n```\n","# Sweep\n\nSmall fixes cost little to make and a lot to run one at a time. Sweep pays the exploration and\nreview once for the whole batch: the label it files under is a feature label as far as\n`\u002Ffleet` is concerned, so dispatch, integration and the single PR into `main` all apply.\n\n## 1. Gather\n\n- `gh issue list --state open --label inbox --json number,title,body`\n- Any items in the user's message, split into one item per distinct fix.\n\nNothing from either source: say the inbox is empty and stop.\n\n## 2. Explore once\n\nLocate every item in a single pass, never one per item. With a `.codegraph\u002F` index, one\n`codegraph_explore` naming every item's symbols and files. Otherwise one `Explore` subagent with\n`model: \"haiku\"`, given the whole list, returning per item: the files and symbols involved, and a\nrough size (lines, files).\n\n## 3. Reject what isn't small\n\nAn item stays in the sweep only if all hold:\n\n- it changes existing behaviour or code, not a new feature;\n- about 80 lines or fewer, across 1–3 files;\n- no schema, public API or dependency change;\n- the cause is known. A bug whose cause still needs finding is triage, not a sweep item.\n\nRejects are listed with their route: `triage-issue` for an unexplained bug, `capture-idea` or\n`to-prd` for a feature, and `needs-design` for a design or refactor concern with no known fix\n(such as a `REFLECT later:` marker). Name no skill for `needs-design`: deciding the fix is the\nopen work. A rejected inbox issue stays open but leaves the inbox in step 6, or every later\nsweep explores and rejects it again.\n\n## 4. Cluster by file\n\nItems that touch a common file go into one ticket, transitively: if A shares a file with B and B\nwith C, all three are one ticket. Disjoint items stay separate tickets, so they run in parallel\nwithout conflicting.\n\nIf a cluster grows past about 3 files or 150 lines, split it back into tickets and chain them\nwith `## Blocked by` in item order, so `\u002Ffleet` runs them in successive waves instead of\ncolliding.\n\nSize each ticket: `size:xs` when it touches one file and needs at most one new test case,\notherwise `size:s`.\n\n## 5. Confirm the batch\n\nShow one table and wait for a yes. The clustering is the decision, so this is the one confirm:\n\n```\nLabel: sweep-2026-10-07\n| Ticket | Items (inbox #) | Files | Size |\nRejected: \u003Citem> (inbox #) → \u003Croute>\n```\n\n## 6. File\n\nLabel: `sweep-YYYY-MM-DD` with today's date. If that label already has open issues, append\n`-2`, `-3`, … so a dispatched batch never gains tickets mid-flight. Create the label with\n`gh label create \"\u003Clabel>\" -d \"Sweep of small fixes\"`, and `size:xs` \u002F `size:s` if missing.\n\nEach ticket uses file-issue's body (`## Context`, `## Where to look`, `## Acceptance criteria`)\nwith step 2's findings as \"Where to look\", plus:\n\n```markdown\n## Items\n\n- \u003Citem> (from #\u003Cinbox issue>)\n\n## Blocked by\n\nNone\n```\n\nAcceptance criteria: one or two per item.\n\n```bash\ngh issue create --title \"\u003Ctitle>\" --body-file \u003Ctmpfile> \\\n  --label \"\u003Csweep label>\" --label \"status:ready\" --label \"size:\u003Cxs|s>\"\n```\n\nA chained ticket from step 4 gets `status:backlog` and a `- Blocked by #\u003CN>` line instead.\nThen close every absorbed inbox issue: `gh issue close \u003CN> --comment \"Swept into #\u003Cticket>\"`.\n\nTake every reject that came from an inbox issue out of the inbox with\n`gh issue edit \u003CN> --remove-label inbox`. A `needs-design` reject also gets\n`--add-label needs-design`; create that label first if missing:\n`gh label create needs-design -d \"Needs a design decision before it can be fixed\"`.\n\n## 7. Report\n\nThe tickets as `#\u003CN> \u003Ctitle> (size)`, one per line, then the rejects with their route, then the\ncommand on its own line:\n\n```\n\u002Ffleet dispatch \u003Csweep label>\n```\n",{"name":5,"description":43,"disable-model-invocation":44},"Turn a pile of small fixes into a batch \u002Ffleet can dispatch. Takes the open `inbox` issues and any items pasted with the command, explores them in one pass, rejects anything too big for a small fix and takes it out of the inbox, merges items that touch the same files into one ticket, and files the tickets under one dated `sweep-YYYY-MM-DD` label. Use for \"sweep the inbox\", \"batch these fixes\", \"turn these into tickets and fleet them\". For one ad-hoc ticket, use file-issue; for a feature, use \u002Fto-tickets.\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fsweep","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 04:20:46",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":44},[55,58,61],{"tool":56,"command":57},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill sweep",{"tool":59,"command":60},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill sweep",{"tool":62,"command":63},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill sweep","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fsweep\u002FSKILL.md",[66],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"evals\u002Fevals.json","REFERENCE","参考文档",721,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fsweep\u002Fevals\u002Fevals.json",[73,95,122,149,171,190],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":38},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[80,81,82,83,84,36,85,86,87,33,88,89,90,28,91,92,93,27,23,21,94],"to tickets","tickets","github","run","code","manifest","plan","repo","worktrees","task","signatures","plans","as","cut","new",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":106,"publishedAt":38},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[107,108,109,35,87,110,33,31,111,112,113,114,115,92,116,117,118,119,23,22,21,120,121,94],"to seams","writing","repos","prompt","schema","build","but","either","record","records","it","block","interface","neither","when",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":133,"publishedAt":38},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[128],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[134,135,136,86,137,138,139,140,141,142,28,92,27,143,144,81,145,146,147,23,148,121],"roadmap","to roadmap","doc","board","never","later","next","self","ideas","via","card","now","about","re","features",{"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":156,"publishedAt":38},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[155],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},[157,158,159,160,86,161,162,163,28,92,164,165,81,166,167,168,147,23,169,170],"to prd","prd","report","state","ask","say","delivery","line","problem","spine","multi","interviews","which","codebase",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":38},"01M6H881QEEP49HPBMDYDFJQP9","to-plan","Turns one feature's PRD into a skimmable plan in docs\u002Fplans\u002F\u003Cfeature>.md: a short overview, then per phase a glossary, the journeys it satisfies, and its new and modified definitions (types, enums, ports, schema), with the project:\u003Cslug> label. No code, branch or PR; the user's review of the file is the gate. Use for \"plan this feature\", \"write the contract\", \"what are the types\". One feature per run. Slash-only.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002FSKILL.md",[],[86,178,179,84,35,180,181,182,183,184,31,111,185,186,187,28,91,188,23,21,189,94],"to plan","pr","ports","glossary","branch","short","overview","only","project","contract","types","\u003Cslug>",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":38},"01M6H87XEQEXSGT0PR5QWQZZ5P","ticket-tracker","Use when the request is about the *current state* of GitHub issues rather than creating new ones: \"where are my tickets\", \"show the board\", \"what's in progress\", \"what's ready to pick up\", \"move issue N to in-review\", \"mark N done\", \"update the ticket status\". Live triage board over GitHub issues via the gh CLI, moving each between backlog -> ready -> in-progress -> in-review -> done using status labels. This is the ticket-level board; .\u002Fideas\u002Froadmap.html is the feature-level one. To file new tickets, use \u002Fto-tickets, file-issue for a single ad-hoc one, or \u002Fsweep for a batch of small fixes.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fticket-tracker\u002FSKILL.md",[],[197,27,198,199,200,201,202,37,36,35,203,204,31,205,134,206,207,208,209,142,28,210,211,21,20,212,213,121,94],"tracker","ticket tracker","review","cli","current state","update","gh","pick","ready","up","show","done","backlog","progress","move","labels","request"]