[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H88J6TYRV9T8RKWW569YM8":3,"skill-same:01M6H88J6TYRV9T8RKWW569YM8":78},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":14,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":67},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets",null,"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.","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-tickets\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"to tickets","tickets","new","github","for","true","ticket","cut","as","plans","feature","signatures","task","worktrees","command","repo","plan","manifest","batch","code","run","2026-11-10 10:12:30",false,"---\nname: to-tickets\ndescription: >\n  Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the\n  plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly\n  one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's\n  slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers\n  \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a\n  plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.\ndisable-model-invocation: true\n---\n\n# Plan to 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                                                        ↓  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                                                    ^^^^^^^^^^ you are here\n```\n\n**Portfolio → feature is a fan-out, not a step.** A roadmap card is a *feature*, and this stage turns\nexactly one of them into its several tickets. Never cut tickets for a whole roadmap or approach doc\nin one run.\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: cut tickets from whatever exists, and say so if the\nsource is thin on technical design. The one hard gate is an approved plan for a code feature.\n\nBreak the source into independently-grabbable tickets using vertical slices (tracer bullets). Tickets\nare filed on GitHub only.\n\n## Process\n\n### 1. Locate the source\n\nIf the user named a source, use it. Otherwise `ls .\u002Fdocs\u002Fplans\u002F*.md .\u002Fdocs\u002Fprds\u002F*.md 2>\u002Fdev\u002Fnull`.\nSeveral present means several features: confirm which one rather than defaulting to the newest.\n\nDecide whether the feature is code or not:\n\n- **Code feature** — the source is the **plan**, `docs\u002Fplans\u002F\u003Cfeature>.md`, in `to-plan`'s format\n  (its `references\u002Fplan-format.md`): a header with `Source:`, `Label:` and `Feature branch:`, then\n  `## Usage`, an optional `## Shared`, `## Slices` whose `new:` blocks and `change:` bullets are the\n  work, and `## Notes`.\n\n  **No approved plan means no tickets.** If there is no plan file, stop and offer `\u002Fto-plan`. If one\n  exists, ask the user to confirm they have reviewed and approved it before drafting; that review is\n  the gate. Never cut a code feature from prose.\n- **Non-code feature** (docs, skills, config) — the source is the PRD, `docs\u002Fprds\u002F\u003Cfeature>.md`, or a\n  `[PRD]`-titled GitHub issue (`gh issue view \u003Cnumber>`, with comments). Cut from the PRD's slices.\n  A conversation the user pastes stands in for the PRD here.\n\nRecord the source path or issue number. Settle the **feature label** every ticket gets: the plan's\n`Label:` line, else ask the user for one before drafting. Never file unlabelled tickets. Feature\nlabels are `project:\u003Cslug>` (`gh label list`); offer the closest as a suggestion.\n\n### 2. Explore the codebase (optional)\n\nIf you have not already explored the codebase, do so to see how the source maps to existing structure.\n\n### 3. Draft vertical slices\n\nBreak the source into **tracer bullet** tickets. Each is a thin vertical slice that cuts through ALL\nintegration layers end-to-end, NOT a horizontal slice of one layer.\n\nRe-derive slices freely. Do not carry the source's numbering into a ticket title. A ticket called\n\"Phase 3\" or \"Slice 2\" is proof the slice was copied rather than re-derived, so name it for what it\ndelivers. The plan's slices are a starting point and its `Slice:` number is recorded on the\nticket; a ticket may still merge or split them. The plan's `## Shared` section, when present, is its\nown ticket that blocks every ticket using it.\n\nFor a code feature, **every new or changed symbol belongs to exactly one ticket**. After drafting,\nlist the plan's `new:` signatures and `change:` bullets against the tickets and fix any that is\nuncovered or claimed twice.\n\nSlices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.\n\n\u003Cvertical-slice-rules>\n- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI)\n- A completed slice is demoable or verifiable on its own\n- Prefer many thin slices over few thick ones\n- Respect **deep modules**: substantial functionality behind a simple, stable, isolation-testable interface. A slice should build or extend a deep module behind its interface, not splay logic across shallow ones.\n- A blocking edge is real when the blocked slice uses a symbol another ticket introduces, its type or its behaviour: nothing exists in code until that ticket lands. Using an existing symbol another ticket only changes is an edge only if it needs the changed behaviour. **Sequence in the source is not a dependency.** Given an ordered list and no criteria, the cheapest consistent answer is \"each waits for the previous\", and that answer is almost always wrong.\n- Slice by feature, never by layer. \"Extract helpers\", then \"core function\", then \"CLI wiring\", then \"docs\" is a horizontal decomposition wearing four ticket titles, and it is serial by construction.\n\u003C\u002Fvertical-slice-rules>\n\n### 4. Quiz the user\n\nPresent the proposed breakdown as a numbered list. For each slice, show:\n\n- **Title**: short descriptive name\n- **Type**: HITL \u002F AFK\n- **Blocked by**: which other slices (if any) must complete first\n- **Symbols**: the new and changed `file:symbol` list (code feature), or the PRD slices covered (non-code)\n\n#### Measure the graph before proposing it\n\nPrint these three numbers alongside the breakdown, every run:\n\n- **Day-one width** — how many slices have no blockers. This is how many agents can start at once.\n- **Longest chain** — the deepest path through the blocking graph.\n- **Acceptance criteria per slice** — a count each.\n\nTarget shape: day-one width of 3 or more, longest chain of 4 or less, roughly 3 acceptance criteria a\nslice. A slice carrying 10 criteria is doing several things, and splitting it usually produces slices\nthat do not block each other.\n\n**Stop and re-derive when day-one width is 1 and there are more than 3 slices.** Width 1 means the\nfleet runs one agent and the parallelism is decorative. Never create a width-1 graph without the user\nexplicitly telling you to proceed.\n\nDepth is a review-latency multiplier, so shallow and wide beats deep and narrow. It costs a staggered\nstart, since each layer waits for the layer below to *open* a pull request rather than to merge, and\nthen a serial merge tail, since a stack merges bottom-up. The last layer's agent can start early and\nstill land last.\n\nSome convergence is genuine. Every phase of command-center really did touch `loop.go`, `server.go`\nand `plan.go`, and forcing those apart would have produced tickets that conflict rather than tickets\nthat parallelise. So the gate asks you to justify each edge, not to invent independence: if the\nslices truly stack, name the shared file or type that forces it and carry on.\n\nAsk the user:\n\n- Does the granularity feel right? (too coarse \u002F too fine)\n- Which blocking edges are wrong? For each one kept, which symbol does it wait on?\n- Should any slices be merged or split further?\n- Are the correct slices marked as HITL and AFK?\n\nIterate until the user approves the breakdown.\n\n### 5. Create the tickets\n\nFor each approved slice, run `gh issue create --title \"\u003Ctitle>\" --body-file \u003Cfile>` with the body\ntemplate below. Create in **dependency order (blockers first)**, so a blocker already has a real\nissue number by the time the ticket it blocks is created. Blocking is prose only: the body's\n\"Blocked by\" section carries `#\u003Cnumber>`.\n\n\u003Cticket-template>\n\u003CSource-reference header, pick ONE:>\n\u003C  Plan:         \"## Source plan\" + `docs\u002Fplans\u002F\u003Cfeature>.md` + `Feature branch: \u003Cbranch>`>\n\u003C  PRD:          \"## Parent PRD\" + `docs\u002Fprds\u002F\u003Cfeature>.md` and\u002For #\u003Cprd-issue-number>>\n\nSlice: \u003Cn>\nJourneys: \u003Cn, …>   (non-code feature: the PRD's journey numbers, or \"none\" if it lists none)\n\n## Signatures\n\n\u003CCode feature: replaces prose \"What to build\". Copy the slice's `new:` blocks and `change:` bullets\nverbatim from the plan, plus the `## Usage` blocks for its journeys: the plan may be gitignored, so\nthe ticket must carry everything an implementer in a fresh worktree needs.>\n\nSignatures are frozen. Changing one is a `contract-change` issue, not an edit in this ticket.\n\nnew:\n```\u003Clang>\n\u002F\u002F path\u002Fto\u002Ffile.go\nfunc …\n```\n\n- change: `path\u002Fto\u002Fexisting.go:Symbol` — what changes\n\n\u003CNon-code feature: use \"## What to build\" instead, a concise description of the slice, referencing the PRD rather than duplicating it.>\n\n## Acceptance criteria\n\n- [ ] Criterion 1\n- [ ] Criterion 2\n- [ ] Criterion 3\n\n## Blocked by\n\n- Blocked by #\u003Cissue-number> (if any)\n\nOr \"None - can start immediately\" if no blockers.\n\n\u003C\u002Fticket-template>\n\nDo NOT modify the plan or the PRD.\n\n### 6. Hand off to the board\n\nSlices with no blockers are grabbable now; anything blocked by another slice is not, and lands\nbehind it. State rides on a `status:*` label, and the feature label from step 1 goes on every\nticket. Apply both after creation:\n\n```bash\ngh issue edit \u003Cnumber> --add-label \"status:ready\" --add-label \"\u003Cfeature-label>\"   # blocked slices: status:backlog\n```\n\nIf the feature label doesn't exist yet, create it first with\n`gh label create \"\u003Cfeature-label>\" -d \"\u003CFeature Name> (docs\u002Fprds\u002F\u003Cslug>.md)\"`.\n\nIf those labels don't exist in the repo, create the two you need and move on — `status:ready`\n(`-c \"#0e8a16\"`), `status:backlog` (`-c \"#cccccc\"`). `ticket-tracker` owns the full vocabulary;\ndon't invent names beyond these.\n\nReport the created issue numbers with their states and the blocking edges. End with the command that\nruns them: `\u002Ffleet dispatch \u003Cfeature-label>`.\n\nFrom this point `ticket-tracker` owns the tickets — it reads and moves them between states. This\nskill does not track what it files.\n\n### 7. Emit the dependency graph for whatever orchestrates this repo\n\nTwo things can read this graph, and they conflict if both get written: check for command-centre\nfirst, since a command-centre repo already uses treepad internally to cut its worktrees, and a\nBatch Manifest on top would hand the same worktrees to treepad's own `Reconcile` too.\n\n**command-centre** — check for its config:\n\n```bash\nls \"$(git rev-parse --show-toplevel)\u002F..\u002F.claude\u002Fcommand-centre.toml\" 2>\u002Fdev\u002Fnull\n```\n\n**Absent** — fall through to the treepad check below.\n\n**Present** — for each ticket just created, write or update a `[[task]]` block in that file:\n\n```toml\n[[task]]\nticket_url = \"\u003Cthe ticket's URL>\"\nrepo       = \"\u003Cthe checkout's [[repo]] name>\"\nbranch     = \"\u003Crepo-prefix>-\u003Cissue-number>-\u003Cshort-slug>\"\nblocked_by = [\"\u003Cticket URL>\", …]\nseams      = [\"\u003Cseam name>\", …]\n```\n\nEdges only, no chain semantics: a fan-out (one ticket blocking four) is four `[[task]]` blocks,\neach naming that one blocker — the app derives every base itself. Branch names follow whatever's\nalready in the file for that `[[repo]]` (e.g. `cc-33-fan-out`); check an existing `branch` value\nthere before inventing a new prefix.\n\n**`seams`** names an agreed-but-unlanded interface in another repo that this ticket's agent needs\npasted into its prompt — written by `\u002Fto-seams`, never by this skill. Only a ticket whose slice is\na *consumer* of a seam carries the field; omit it entirely rather than writing `seams = []`, which\nis the same \"no seams\" state a task with the field left out already gets. If a slice you're\ncutting depends on an interface that hasn't landed anywhere yet, that's a sign to run `\u002Fto-seams`\nfirst, then reference the name it gives you — this skill does not invent seam names.\n\n**Upsert on `ticket_url`.** Read the file first. A `[[task]]` block already carrying this ticket's\n`ticket_url` gets its fields replaced in place, so re-running over an edited feature updates rows\nrather than minting duplicates. Otherwise append a new block.\n\nCommand-centre present means skip the treepad Batch Manifest below entirely — don't write both.\n\n**treepad (only when command-centre is absent)** — check for a treepad batches directory:\n\n```bash\nls \"$(git rev-parse --git-common-dir)\u002Ftreepad\u002Fbatches\u002F\"\n```\n\n**Absent** — skip, and say nothing. Most repos use neither and the step is a no-op there.\n\n**Present** — write `\u003Cfeature>.toml` into that directory, per\n[`references\u002Ftreepad-manifest.md`](references\u002Ftreepad-manifest.md). It declares the blocking graph\nfrom step 4 as ordered Chains, which treepad materialises into stacked worktrees. Write it from the\ngraph you already hold — never read the relations back off the tracker.\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","# Plan to 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                                                        ↓  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                                                    ^^^^^^^^^^ you are here\n```\n\n**Portfolio → feature is a fan-out, not a step.** A roadmap card is a *feature*, and this stage turns\nexactly one of them into its several tickets. Never cut tickets for a whole roadmap or approach doc\nin one run.\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: cut tickets from whatever exists, and say so if the\nsource is thin on technical design. The one hard gate is an approved plan for a code feature.\n\nBreak the source into independently-grabbable tickets using vertical slices (tracer bullets). Tickets\nare filed on GitHub only.\n\n## Process\n\n### 1. Locate the source\n\nIf the user named a source, use it. Otherwise `ls .\u002Fdocs\u002Fplans\u002F*.md .\u002Fdocs\u002Fprds\u002F*.md 2>\u002Fdev\u002Fnull`.\nSeveral present means several features: confirm which one rather than defaulting to the newest.\n\nDecide whether the feature is code or not:\n\n- **Code feature** — the source is the **plan**, `docs\u002Fplans\u002F\u003Cfeature>.md`, in `to-plan`'s format\n  (its `references\u002Fplan-format.md`): a header with `Source:`, `Label:` and `Feature branch:`, then\n  `## Usage`, an optional `## Shared`, `## Slices` whose `new:` blocks and `change:` bullets are the\n  work, and `## Notes`.\n\n  **No approved plan means no tickets.** If there is no plan file, stop and offer `\u002Fto-plan`. If one\n  exists, ask the user to confirm they have reviewed and approved it before drafting; that review is\n  the gate. Never cut a code feature from prose.\n- **Non-code feature** (docs, skills, config) — the source is the PRD, `docs\u002Fprds\u002F\u003Cfeature>.md`, or a\n  `[PRD]`-titled GitHub issue (`gh issue view \u003Cnumber>`, with comments). Cut from the PRD's slices.\n  A conversation the user pastes stands in for the PRD here.\n\nRecord the source path or issue number. Settle the **feature label** every ticket gets: the plan's\n`Label:` line, else ask the user for one before drafting. Never file unlabelled tickets. Feature\nlabels are `project:\u003Cslug>` (`gh label list`); offer the closest as a suggestion.\n\n### 2. Explore the codebase (optional)\n\nIf you have not already explored the codebase, do so to see how the source maps to existing structure.\n\n### 3. Draft vertical slices\n\nBreak the source into **tracer bullet** tickets. Each is a thin vertical slice that cuts through ALL\nintegration layers end-to-end, NOT a horizontal slice of one layer.\n\nRe-derive slices freely. Do not carry the source's numbering into a ticket title. A ticket called\n\"Phase 3\" or \"Slice 2\" is proof the slice was copied rather than re-derived, so name it for what it\ndelivers. The plan's slices are a starting point and its `Slice:` number is recorded on the\nticket; a ticket may still merge or split them. The plan's `## Shared` section, when present, is its\nown ticket that blocks every ticket using it.\n\nFor a code feature, **every new or changed symbol belongs to exactly one ticket**. After drafting,\nlist the plan's `new:` signatures and `change:` bullets against the tickets and fix any that is\nuncovered or claimed twice.\n\nSlices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.\n\n\u003Cvertical-slice-rules>\n- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI)\n- A completed slice is demoable or verifiable on its own\n- Prefer many thin slices over few thick ones\n- Respect **deep modules**: substantial functionality behind a simple, stable, isolation-testable interface. A slice should build or extend a deep module behind its interface, not splay logic across shallow ones.\n- A blocking edge is real when the blocked slice uses a symbol another ticket introduces, its type or its behaviour: nothing exists in code until that ticket lands. Using an existing symbol another ticket only changes is an edge only if it needs the changed behaviour. **Sequence in the source is not a dependency.** Given an ordered list and no criteria, the cheapest consistent answer is \"each waits for the previous\", and that answer is almost always wrong.\n- Slice by feature, never by layer. \"Extract helpers\", then \"core function\", then \"CLI wiring\", then \"docs\" is a horizontal decomposition wearing four ticket titles, and it is serial by construction.\n\u003C\u002Fvertical-slice-rules>\n\n### 4. Quiz the user\n\nPresent the proposed breakdown as a numbered list. For each slice, show:\n\n- **Title**: short descriptive name\n- **Type**: HITL \u002F AFK\n- **Blocked by**: which other slices (if any) must complete first\n- **Symbols**: the new and changed `file:symbol` list (code feature), or the PRD slices covered (non-code)\n\n#### Measure the graph before proposing it\n\nPrint these three numbers alongside the breakdown, every run:\n\n- **Day-one width** — how many slices have no blockers. This is how many agents can start at once.\n- **Longest chain** — the deepest path through the blocking graph.\n- **Acceptance criteria per slice** — a count each.\n\nTarget shape: day-one width of 3 or more, longest chain of 4 or less, roughly 3 acceptance criteria a\nslice. A slice carrying 10 criteria is doing several things, and splitting it usually produces slices\nthat do not block each other.\n\n**Stop and re-derive when day-one width is 1 and there are more than 3 slices.** Width 1 means the\nfleet runs one agent and the parallelism is decorative. Never create a width-1 graph without the user\nexplicitly telling you to proceed.\n\nDepth is a review-latency multiplier, so shallow and wide beats deep and narrow. It costs a staggered\nstart, since each layer waits for the layer below to *open* a pull request rather than to merge, and\nthen a serial merge tail, since a stack merges bottom-up. The last layer's agent can start early and\nstill land last.\n\nSome convergence is genuine. Every phase of command-center really did touch `loop.go`, `server.go`\nand `plan.go`, and forcing those apart would have produced tickets that conflict rather than tickets\nthat parallelise. So the gate asks you to justify each edge, not to invent independence: if the\nslices truly stack, name the shared file or type that forces it and carry on.\n\nAsk the user:\n\n- Does the granularity feel right? (too coarse \u002F too fine)\n- Which blocking edges are wrong? For each one kept, which symbol does it wait on?\n- Should any slices be merged or split further?\n- Are the correct slices marked as HITL and AFK?\n\nIterate until the user approves the breakdown.\n\n### 5. Create the tickets\n\nFor each approved slice, run `gh issue create --title \"\u003Ctitle>\" --body-file \u003Cfile>` with the body\ntemplate below. Create in **dependency order (blockers first)**, so a blocker already has a real\nissue number by the time the ticket it blocks is created. Blocking is prose only: the body's\n\"Blocked by\" section carries `#\u003Cnumber>`.\n\n\u003Cticket-template>\n\u003CSource-reference header, pick ONE:>\n\u003C  Plan:         \"## Source plan\" + `docs\u002Fplans\u002F\u003Cfeature>.md` + `Feature branch: \u003Cbranch>`>\n\u003C  PRD:          \"## Parent PRD\" + `docs\u002Fprds\u002F\u003Cfeature>.md` and\u002For #\u003Cprd-issue-number>>\n\nSlice: \u003Cn>\nJourneys: \u003Cn, …>   (non-code feature: the PRD's journey numbers, or \"none\" if it lists none)\n\n## Signatures\n\n\u003CCode feature: replaces prose \"What to build\". Copy the slice's `new:` blocks and `change:` bullets\nverbatim from the plan, plus the `## Usage` blocks for its journeys: the plan may be gitignored, so\nthe ticket must carry everything an implementer in a fresh worktree needs.>\n\nSignatures are frozen. Changing one is a `contract-change` issue, not an edit in this ticket.\n\nnew:\n```\u003Clang>\n\u002F\u002F path\u002Fto\u002Ffile.go\nfunc …\n```\n\n- change: `path\u002Fto\u002Fexisting.go:Symbol` — what changes\n\n\u003CNon-code feature: use \"## What to build\" instead, a concise description of the slice, referencing the PRD rather than duplicating it.>\n\n## Acceptance criteria\n\n- [ ] Criterion 1\n- [ ] Criterion 2\n- [ ] Criterion 3\n\n## Blocked by\n\n- Blocked by #\u003Cissue-number> (if any)\n\nOr \"None - can start immediately\" if no blockers.\n\n\u003C\u002Fticket-template>\n\nDo NOT modify the plan or the PRD.\n\n### 6. Hand off to the board\n\nSlices with no blockers are grabbable now; anything blocked by another slice is not, and lands\nbehind it. State rides on a `status:*` label, and the feature label from step 1 goes on every\nticket. Apply both after creation:\n\n```bash\ngh issue edit \u003Cnumber> --add-label \"status:ready\" --add-label \"\u003Cfeature-label>\"   # blocked slices: status:backlog\n```\n\nIf the feature label doesn't exist yet, create it first with\n`gh label create \"\u003Cfeature-label>\" -d \"\u003CFeature Name> (docs\u002Fprds\u002F\u003Cslug>.md)\"`.\n\nIf those labels don't exist in the repo, create the two you need and move on — `status:ready`\n(`-c \"#0e8a16\"`), `status:backlog` (`-c \"#cccccc\"`). `ticket-tracker` owns the full vocabulary;\ndon't invent names beyond these.\n\nReport the created issue numbers with their states and the blocking edges. End with the command that\nruns them: `\u002Ffleet dispatch \u003Cfeature-label>`.\n\nFrom this point `ticket-tracker` owns the tickets — it reads and moves them between states. This\nskill does not track what it files.\n\n### 7. Emit the dependency graph for whatever orchestrates this repo\n\nTwo things can read this graph, and they conflict if both get written: check for command-centre\nfirst, since a command-centre repo already uses treepad internally to cut its worktrees, and a\nBatch Manifest on top would hand the same worktrees to treepad's own `Reconcile` too.\n\n**command-centre** — check for its config:\n\n```bash\nls \"$(git rev-parse --show-toplevel)\u002F..\u002F.claude\u002Fcommand-centre.toml\" 2>\u002Fdev\u002Fnull\n```\n\n**Absent** — fall through to the treepad check below.\n\n**Present** — for each ticket just created, write or update a `[[task]]` block in that file:\n\n```toml\n[[task]]\nticket_url = \"\u003Cthe ticket's URL>\"\nrepo       = \"\u003Cthe checkout's [[repo]] name>\"\nbranch     = \"\u003Crepo-prefix>-\u003Cissue-number>-\u003Cshort-slug>\"\nblocked_by = [\"\u003Cticket URL>\", …]\nseams      = [\"\u003Cseam name>\", …]\n```\n\nEdges only, no chain semantics: a fan-out (one ticket blocking four) is four `[[task]]` blocks,\neach naming that one blocker — the app derives every base itself. Branch names follow whatever's\nalready in the file for that `[[repo]]` (e.g. `cc-33-fan-out`); check an existing `branch` value\nthere before inventing a new prefix.\n\n**`seams`** names an agreed-but-unlanded interface in another repo that this ticket's agent needs\npasted into its prompt — written by `\u002Fto-seams`, never by this skill. Only a ticket whose slice is\na *consumer* of a seam carries the field; omit it entirely rather than writing `seams = []`, which\nis the same \"no seams\" state a task with the field left out already gets. If a slice you're\ncutting depends on an interface that hasn't landed anywhere yet, that's a sign to run `\u002Fto-seams`\nfirst, then reference the name it gives you — this skill does not invent seam names.\n\n**Upsert on `ticket_url`.** Read the file first. A `[[task]]` block already carrying this ticket's\n`ticket_url` gets its fields replaced in place, so re-running over an edited feature updates rows\nrather than minting duplicates. Otherwise append a new block.\n\nCommand-centre present means skip the treepad Batch Manifest below entirely — don't write both.\n\n**treepad (only when command-centre is absent)** — check for a treepad batches directory:\n\n```bash\nls \"$(git rev-parse --git-common-dir)\u002Ftreepad\u002Fbatches\u002F\"\n```\n\n**Absent** — skip, and say nothing. Most repos use neither and the step is a no-op there.\n\n**Present** — write `\u003Cfeature>.toml` into that directory, per\n[`references\u002Ftreepad-manifest.md`](references\u002Ftreepad-manifest.md). It declares the blocking graph\nfrom step 4 as ordered Chains, which treepad materialises into stacked worktrees. Write it from the\ngraph you already hold — never read the relations back off the tracker.\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":45,"disable-model-invocation":46},"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.\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fto-tickets","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 22:26:34",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":46},[57,60,63],{"tool":58,"command":59},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-tickets",{"tool":61,"command":62},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-tickets",{"tool":64,"command":65},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-tickets","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[68,74],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"evals\u002Fevals.json","REFERENCE","参考文档",11801,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002Fevals\u002Fevals.json",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Ftreepad-manifest.md",4924,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002Freferences\u002Ftreepad-manifest.md",[79,87,94,124,151,173],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":86},"01M745F5J4Z2W32G4QXESCN5PM","vault-recall","Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fvault-recall\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"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":86},"01M745EW5W0A7K9016Z54A4KG2","ingest","Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw\u002F, then build wiki\u002F pages per the vault's § Ingest. Use when the user types \u002Fingest, or says \"ingest this\", \"add this source to my wiki\", \"put this article\u002Flesson in the vault as a wiki page\". Works from any repo. Routing rule: someone else's words go to wiki\u002F (this skill); the user's own learnings and decisions go to notes\u002F (\u002Fto-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fingest\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":105,"publishedAt":40},"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",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[106,107,27,108,109,110,111,112,113,114,115,116,117,24,118,119,120,34,23,121,122,21,33,123],"to seams","when","can","repos","but","file","prompt","either","use","writing","schema","interface","it","block","records","build","neither","record",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":135,"publishedAt":40},"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",[130],{"categoryNo":131,"categoryName":132,"taxonomyType":133,"taxonomyTypeDesc":134},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[136,137,35,138,107,139,140,141,20,142,143,144,145,146,24,25,147,148,149,150,27,29],"to roadmap","roadmap","features","doc","board","about","next","via","later","self","now","card","re","ideas","never",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":40},"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",[157],{"categoryNo":131,"categoryName":132,"taxonomyType":133,"taxonomyTypeDesc":134},[159,160,27,35,161,162,163,164,165,20,166,167,168,169,170,24,148,29,171,172],"prd","to prd","interviews","codebase","report","line","delivery","spine","say","state","multi","ask","problem","which",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":40},"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",[],[180,35,181,21,182,38,111,183,114,116,184,185,28,24,186,187,23,29,188,189,190,191],"to plan","overview","\u003Cslug>","glossary","only","contract","short","project","types","pr","branch","ports"]