[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H889PSQM2E1ATS2JC10QRV":3,"skill-same:01M6H889PSQM2E1ATS2JC10QRV":86},{"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":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":73},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap",null,"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.","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\u002Fto-roadmap\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"to roadmap","roadmap","ticket","when","features","true","re","about","now","tickets","card","via","doc","as","feature","ideas","self","next","later","never","board","plan","2026-11-10 10:12:30",false,"---\nname: to-roadmap\ndescription: >\n  Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a\n  self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes\n  several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in\n  .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach\n  doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it\n  never re-litigates what was decided.\ndisable-model-invocation: true\n---\n\n## Overview\n\nTurn the features you have settled on into a visual product roadmap: a standalone HTML\nkanban with three columns (Now \u002F Next \u002F Later) where each card is a **feature**, not a ticket — a\nthing to be built, which the spine later breaks down into several tickets.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                    ^^^^^^^^^^^^ you are here\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** This skill is portfolio-level: it prioritises many\nfeatures at once. Crossing to the spine means picking one card — six cards means six independent\nruns of `to-prd → to-plan → to-tickets`, each producing its own several tickets.\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan.\n\nBoard from `.\u002Fdocs\u002Fapproach.md`, from `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`, or from a short\nlist the user gives you. The one thing this skill will not do\nis build a roadmap by parsing a raw conversation — `chat-to-approach` owns that (see Phase 0).\n\nSolo\u002Findie-builder scale throughout: no assignees, no story points, no sprints, no stakeholder\nmatrices.\n\n---\n\n## Phase 0 — Load the source\n\nTwo sources, in priority order. Run `artifact-scan` as a preflight if it's installed rather than\nreimplementing its file checks.\n\n**1. `.\u002Fdocs\u002Fapproach.md`** — the alignment doc, and the richer source. Read it and extract,\ntreating every item as already agreed:\n\n- All features (Name, Problem, Value, Dependencies) → cards\n- Constraints → a note below the board, not cards\n- Principles → use to inform tier suggestions (e.g. \"ship weekly\" → fewer Now items)\n- Open questions → carry forward verbatim into the Open Questions section\n\n**2. `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`** — the ideas the user has decided to build,\nwhether `ideate` promoted them or they were hand-added. One line each, one card each. Accepting is\nthe selection, so board the whole section rather than asking which of them to include.\n\nDo not modify either file.\n\n**If both exist**, the approach doc wins: it has been grilled, and it carries the constraints,\nprinciples and open questions a bare idea list doesn't.\n\n**If neither exists**, ask the user for the features to board — a short list, one line each — and\nmention that `ideate` or `chat-to-approach` leaves a durable source next time. What you must not do\nis build the board by parsing a pasted conversation: `chat-to-approach` owns conversation →\nstructure, including the grilling that resolves ambiguity before anything is committed. Two skills\nparsing transcripts differently is how a board ends up built on ungrilled assumptions.\n\nA feature too vague to tier is not a licence to re-litigate it. Say so, and either ask the user for\na tier directly or point them back at the source to sharpen it.\n\n---\n\n## Phase 1 — Prioritise\n\nAssign each feature a tier. Offer a suggested tier per feature — biasing dependency-blocking\nfeatures toward Now and anything speculative toward Later — and let the user confirm or override in\none pass.\n\n**Now** — Committed, ready to start, essential for current momentum. If the user isn't working on\nit this week or next, it's not Now.\n\n**Next** — Decided but intentionally deferred. Depends on Now items finishing first, or deliberately\nheld back to maintain focus.\n\n**Later** — Someday \u002F low urgency \u002F speculative. Worth keeping visible so nothing falls through the\ncracks, but not near-term.\n\n**Why this ordering — the prioritisation lens.** A tier is a decision, not a guess. When a feature's\ntier is unclear, reason it out against four levers:\n\n- **Value** — how much user pain it removes or upside it unlocks. High value pulls toward Now.\n- **Effort** — rough size. High value + low effort is the classic Now; high effort earns Next\u002FLater\n  unless it's blocking.\n- **Dependency** — does other work need this first? A blocker for several features earns Now even if\n  its own value is modest; something that depends on unfinished work can't be Now.\n- **Risk** — uncertainty or the cost of getting it wrong. De-risk early when a wrong call is\n  expensive to unwind; defer speculative bets to Later.\n\nState the *why* in one clause when you suggest a tier (e.g. \"Now — blocks capture and auth\"), so the\nordering is auditable rather than arbitrary.\n\nDefault to fewer Now items. A solo builder can realistically focus on 2–4 things at once. If\neverything looks like Now, something is wrong — push back and ask.\n\n---\n\n## Phase 2 — Generate the board\n\nWrite a complete, self-contained HTML file to `.\u002Fideas\u002Froadmap.html` in the current working directory.\nRun `mkdir -p .\u002Fideas` first — the directory may not exist yet. It shares a home with the ideate\nreports so a project only has one path to gitignore.\n\n**Always write the file.** Other skills detect this stage with `test -f .\u002Fideas\u002Froadmap.html`, so a board\nthat only ever existed as a chat artifact leaves the repo looking like no roadmap was made. Render\nit as an artifact too if the interface supports it, but the file is the deliverable, not the copy.\n\nUse `assets\u002Froadmap-template.html` as the starting point — inline CSS, no external dependencies, no\nJavaScript. Replace its placeholder comments with the actual cards and questions.\n\n### Card format\n\nEach card represents a **feature** and shows:\n\n- A short noun-phrase title naming the feature (e.g. \"User authentication\", \"Onboarding flow\")\n- One sentence describing the user problem it solves or the value it delivers\n- A dependency line only if it blocks or is blocked by another feature on the board\n\nNothing else — no assignees, no tags, no dates, no story points, no implementation tasks.\n\n### Open questions format\n\nBelow the board, list each open question from the approach doc as a numbered item: the question\nconcisely, plus a one-line note on why it matters or what's blocked on it.\n\n```\nNow (amber)  |  Next (blue)  |  Later (slate)\n─────────────────────────────────────────────\n[ Card ]       [ Card ]        [ Card ]\n[ Card ]       [ Card ]\n[ Card ]\n\nOpen Questions\n──────────────\n1. Should auth use JWT or sessions? — blocks mobile client work.\n2. Is the pricing page in scope for v1?\n```\n\n---\n\n## Finishing Up\n\nAfter writing the file, a brief summary (3–5 lines max). It's a receipt, not a re-explanation —\ndon't repeat the roadmap verbatim.\n\n- How many features are on the board and how they're distributed (N Now \u002F N Next \u002F N Later)\n- How many open questions were flagged\n- Which source was used, left unmodified — to change what's on the board, edit the source\n  (`chat-to-approach` for the approach doc, or the `## Accepted ideas` list directly) and re-run\n- The next step: pick one card and run `to-prd` on it. Each card is its own pass down the spine.\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke skill-feedback-collector passing this skill's name and path.\n","## Overview\n\nTurn the features you have settled on into a visual product roadmap: a standalone HTML\nkanban with three columns (Now \u002F Next \u002F Later) where each card is a **feature**, not a ticket — a\nthing to be built, which the spine later breaks down into several tickets.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                    ^^^^^^^^^^^^ you are here\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** This skill is portfolio-level: it prioritises many\nfeatures at once. Crossing to the spine means picking one card — six cards means six independent\nruns of `to-prd → to-plan → to-tickets`, each producing its own several tickets.\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan.\n\nBoard from `.\u002Fdocs\u002Fapproach.md`, from `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`, or from a short\nlist the user gives you. The one thing this skill will not do\nis build a roadmap by parsing a raw conversation — `chat-to-approach` owns that (see Phase 0).\n\nSolo\u002Findie-builder scale throughout: no assignees, no story points, no sprints, no stakeholder\nmatrices.\n\n---\n\n## Phase 0 — Load the source\n\nTwo sources, in priority order. Run `artifact-scan` as a preflight if it's installed rather than\nreimplementing its file checks.\n\n**1. `.\u002Fdocs\u002Fapproach.md`** — the alignment doc, and the richer source. Read it and extract,\ntreating every item as already agreed:\n\n- All features (Name, Problem, Value, Dependencies) → cards\n- Constraints → a note below the board, not cards\n- Principles → use to inform tier suggestions (e.g. \"ship weekly\" → fewer Now items)\n- Open questions → carry forward verbatim into the Open Questions section\n\n**2. `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`** — the ideas the user has decided to build,\nwhether `ideate` promoted them or they were hand-added. One line each, one card each. Accepting is\nthe selection, so board the whole section rather than asking which of them to include.\n\nDo not modify either file.\n\n**If both exist**, the approach doc wins: it has been grilled, and it carries the constraints,\nprinciples and open questions a bare idea list doesn't.\n\n**If neither exists**, ask the user for the features to board — a short list, one line each — and\nmention that `ideate` or `chat-to-approach` leaves a durable source next time. What you must not do\nis build the board by parsing a pasted conversation: `chat-to-approach` owns conversation →\nstructure, including the grilling that resolves ambiguity before anything is committed. Two skills\nparsing transcripts differently is how a board ends up built on ungrilled assumptions.\n\nA feature too vague to tier is not a licence to re-litigate it. Say so, and either ask the user for\na tier directly or point them back at the source to sharpen it.\n\n---\n\n## Phase 1 — Prioritise\n\nAssign each feature a tier. Offer a suggested tier per feature — biasing dependency-blocking\nfeatures toward Now and anything speculative toward Later — and let the user confirm or override in\none pass.\n\n**Now** — Committed, ready to start, essential for current momentum. If the user isn't working on\nit this week or next, it's not Now.\n\n**Next** — Decided but intentionally deferred. Depends on Now items finishing first, or deliberately\nheld back to maintain focus.\n\n**Later** — Someday \u002F low urgency \u002F speculative. Worth keeping visible so nothing falls through the\ncracks, but not near-term.\n\n**Why this ordering — the prioritisation lens.** A tier is a decision, not a guess. When a feature's\ntier is unclear, reason it out against four levers:\n\n- **Value** — how much user pain it removes or upside it unlocks. High value pulls toward Now.\n- **Effort** — rough size. High value + low effort is the classic Now; high effort earns Next\u002FLater\n  unless it's blocking.\n- **Dependency** — does other work need this first? A blocker for several features earns Now even if\n  its own value is modest; something that depends on unfinished work can't be Now.\n- **Risk** — uncertainty or the cost of getting it wrong. De-risk early when a wrong call is\n  expensive to unwind; defer speculative bets to Later.\n\nState the *why* in one clause when you suggest a tier (e.g. \"Now — blocks capture and auth\"), so the\nordering is auditable rather than arbitrary.\n\nDefault to fewer Now items. A solo builder can realistically focus on 2–4 things at once. If\neverything looks like Now, something is wrong — push back and ask.\n\n---\n\n## Phase 2 — Generate the board\n\nWrite a complete, self-contained HTML file to `.\u002Fideas\u002Froadmap.html` in the current working directory.\nRun `mkdir -p .\u002Fideas` first — the directory may not exist yet. It shares a home with the ideate\nreports so a project only has one path to gitignore.\n\n**Always write the file.** Other skills detect this stage with `test -f .\u002Fideas\u002Froadmap.html`, so a board\nthat only ever existed as a chat artifact leaves the repo looking like no roadmap was made. Render\nit as an artifact too if the interface supports it, but the file is the deliverable, not the copy.\n\nUse `assets\u002Froadmap-template.html` as the starting point — inline CSS, no external dependencies, no\nJavaScript. Replace its placeholder comments with the actual cards and questions.\n\n### Card format\n\nEach card represents a **feature** and shows:\n\n- A short noun-phrase title naming the feature (e.g. \"User authentication\", \"Onboarding flow\")\n- One sentence describing the user problem it solves or the value it delivers\n- A dependency line only if it blocks or is blocked by another feature on the board\n\nNothing else — no assignees, no tags, no dates, no story points, no implementation tasks.\n\n### Open questions format\n\nBelow the board, list each open question from the approach doc as a numbered item: the question\nconcisely, plus a one-line note on why it matters or what's blocked on it.\n\n```\nNow (amber)  |  Next (blue)  |  Later (slate)\n─────────────────────────────────────────────\n[ Card ]       [ Card ]        [ Card ]\n[ Card ]       [ Card ]\n[ Card ]\n\nOpen Questions\n──────────────\n1. Should auth use JWT or sessions? — blocks mobile client work.\n2. Is the pricing page in scope for v1?\n```\n\n---\n\n## Finishing Up\n\nAfter writing the file, a brief summary (3–5 lines max). It's a receipt, not a re-explanation —\ndon't repeat the roadmap verbatim.\n\n- How many features are on the board and how they're distributed (N Now \u002F N Next \u002F N Later)\n- How many open questions were flagged\n- Which source was used, left unmodified — to change what's on the board, edit the source\n  (`chat-to-approach` for the approach doc, or the `## Accepted ideas` list directly) and re-run\n- The next step: pick one card and run `to-prd` on it. Each card is its own pass down the spine.\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke skill-feedback-collector passing this skill's name and path.\n",{"name":5,"description":51,"disable-model-invocation":52},"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.\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fto-roadmap","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":62,"prompt":72,"zipAvailable":52},[63,66,69],{"tool":64,"command":65},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-roadmap",{"tool":67,"command":68},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-roadmap",{"tool":70,"command":71},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-roadmap","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[74,80],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"assets\u002Froadmap-template.html","ASSET","资产文件",3710,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002Fassets\u002Froadmap-template.html",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Fevals.json","REFERENCE","参考文档",5257,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002Fevals\u002Fevals.json",[87,109,138,160,179,205],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":46},"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",[],[94,33,95,96,97,98,99,45,100,101,102,103,104,38,105,37,106,26,29,107,108],"to tickets","github","run","code","batch","manifest","repo","command","worktrees","task","signatures","plans","cut","for","new",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":120,"publishedAt":46},"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",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[121,122,123,124,100,125,101,126,127,128,129,130,131,37,132,133,134,135,29,136,107,137,27,108],"to seams","writing","repos","file","prompt","use","schema","build","but","either","record","records","it","block","interface","can","neither",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":46},"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",[144],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[146,147,148,149,45,150,151,152,38,37,153,154,33,155,156,157,30,29,158,159],"to prd","prd","report","state","ask","say","delivery","line","problem","spine","multi","interviews","which","codebase",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":46},"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",[],[45,167,168,97,124,169,170,171,172,173,126,127,174,175,176,38,105,177,29,107,178,108],"to plan","pr","ports","glossary","branch","short","overview","only","project","contract","types","\u003Cslug>",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":46},"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",[],[186,26,187,188,189,190,191,192,98,124,193,194,126,195,25,196,197,198,199,39,38,200,201,107,202,203,204,27,108],"tracker","ticket tracker","review","cli","current state","update","issues","gh","pick","ready","up","show","done","backlog","progress","move","fixes","labels","request",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":46},"01M6H87SQHTYJGP904Y5NJD2SP","sweep","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.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fsweep\u002FSKILL.md",[],[207,212,192,98,124,213,101,214,126,215,216,38,26,217,218,219,29,136,107,202],"inbox","open","fix","dispatch","files","touch","mm","with"]