[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H84MSFHBM0K1Y568RZP9M8":3,"skill-same:01M6H84MSFHBM0K1Y568RZP9M8":73},{"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":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6H84MSFHBM0K1Y568RZP9M8","subagent-creator",null,"Designs a lean Claude Code subagent, or widens one on request. Use when the user wants to create, scope or audit a subagent or custom agent, or asks to give an existing one more tools, turns or access. Grills on whether it earns its place before writing anything. Not for writing skills.","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\u002Fmeta\u002Fsubagent-creator\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"creator","subagent","subagent creator","use","when","request","custom","Existing","for","more","it","scope","writing","lean","user","access","Tools","writing skills","audit","code","create","2026-11-10 10:12:30",false,"---\nname: subagent-creator\ndescription: >\n  Designs a lean Claude Code subagent, or widens one on request. Use when the user wants to\n  create, scope or audit a subagent or custom agent, or asks to give an existing one more\n  tools, turns or access. Grills on whether it earns its place before writing anything. Not\n  for writing skills.\n---\n\n# Subagent creator\n\nA subagent is a context firewall with a tool budget: worth having when it keeps noise out of\nthe parent, enforces a restriction, or runs independent work in parallel. It is not a persona.\nThis skill grills first and writes the smallest definition that does the job. It never widens\nan agent on its own initiative: scope grows only when the user asks, and only with evidence.\n\nThree modes. Pick from the user's words:\n\n- **create** (default): grill, write, check.\n- **expand `\u003Cname>`**: only when the user asks. Widen the agent by the smallest step.\n- **audit `\u003Cname>|all`**: check existing agents and report what to cut.\n\n## The rules\n\nEach is enforced in the grill, the template, or the step 4 checklist.\n\n1. **Earn it.** A subagent needs one of four reasons: verbose output the parent doesn't need,\n   an enforced tool restriction, self-contained work that returns a summary, or independent\n   parallel work. No reason means it belongs in the main thread, a skill, a hook or a script.\n2. **Code owns control flow.** Fixed steps (lint, push, label, run CI) are scripts or hooks.\n   The agent covers only the open-ended step.\n3. **Smallest box.** An explicit `tools:` allowlist, read-only by default, MCP servers scoped\n   inline, never inherited wholesale. Every visible tool is a decision the agent can get wrong.\n4. **Single writer.** An agent that writes owns its files and runs in `isolation: worktree`.\n   Reviewers, diagnosers and researchers don't write.\n5. **Fresh means blind.** A fresh agent knows only its prompt and the brief. Say what the brief\n   carries. If it really needs the whole conversation, use a fork instead of a custom agent.\n6. **Artifacts, not transcripts.** The agent returns a short, fixed-format result or a file path.\n7. **Bounded.** `maxTurns` is always set. Use a cheaper model only for bounded, checkable work,\n   never for work that must judge its own limits.\n8. **Few hops.** A chain of more than four agent-to-agent handoffs fails. Split by phase, not\n   by domain.\n9. **Enforce, don't ask.** A rule that matters is a hook or a tool restriction, not a sentence\n   in the prompt.\n10. **Ask, don't improvise.** When the agent hits its scope, it stops and returns a\n    `SCOPE_REQUEST`. That request is the only way scope grows.\n\n## Create\n\n### 1. Look before asking\n\nRead the existing agents in `agents\u002F` (if this repo syncs a top-level `agents\u002F` directory) or\n`.claude\u002Fagents\u002F`, plus `~\u002F.claude\u002Fagents\u002F`. Note any that already overlap the request. That is\na fact you look up yourself, never a question for the user.\n\n### 2. Grill\n\nInvoke the `grilling` skill and pass it this agenda. Work the value branch first. If the value\nbranch fails, recommend the alternative and stop: declining to create an agent is a good\noutcome of this skill.\n\n**Value branch**\n- Which of the four reasons applies? Push back on \"it's a specialist\" with no restriction or\n  isolation behind it.\n- Does an existing agent already do 90% of this? If so, widen that agent or branch inside its\n  prompt instead.\n- Is any of this fixed steps that a script or hook could own (rule 2)?\n- Would a skill (reusable knowledge in the parent context) or a fork (needs the conversation)\n  do better?\n\n**Scope branch**\n- The job in one sentence, plus what \"done\" looks like.\n- What the brief hands it, and what it must not assume it knows.\n- The output contract: format, length cap, or the file it writes.\n- Does it write? Default no. If yes, to which files, and confirm worktree isolation.\n- The smallest tool set that finishes the job. For Bash, which commands, and whether a\n  `PreToolUse` hook should hold it to them.\n- Turn budget and model tier.\n- Will it run in parallel with copies of itself? If so, who owns which files?\n\nRecommend the leanest answer on every question. Widening later is cheap through **expand**, so\nstart small. Don't offer extra tools or turns \"just in case\".\n\n### 3. Write\n\nCopy `assets\u002Fagent-template.md` into the agent directory as `\u003Cname>.md` and fill it in. Keep the\nbody under 40 lines. The description says when to delegate *and* when not to, because it is\nwhat the parent reads to decide.\n\n### 4. Check\n\nRead the finished file against this checklist and fix any failure before showing it:\n\n- `tools` is an explicit allowlist: no wildcard, no omission, and nothing the job doesn't use.\n- `maxTurns` is set.\n- Write tools appear only with `isolation: worktree`.\n- Open `Bash` is held by a `PreToolUse` hook, or justified.\n- The body has an `## Output` section with a fixed format or file path.\n- The body tells the agent to reply `SCOPE_REQUEST: \u003Cwhat> — \u003Cwhy>` when blocked.\n- The description says when to delegate and when not to.\n- No template placeholders remain, and the body is under 40 lines.\n\nShow the user the final file and the grill answer behind each field.\n\n## Expand\n\nRun this only when the user asks to widen an agent. Never propose it unprompted, and never\nwiden an agent as a side effect of another task. A `SCOPE_REQUEST` is a report to the user,\nnot permission to act on it.\n\n1. **Get the evidence.** A `SCOPE_REQUEST` the agent returned, a denied tool call, a\n   `maxTurns` cut-off, or a result that was wrong because the agent lacked access. \"It might\n   need it\" is not evidence. Ask for the run, or find it in the transcript.\n2. **Take the smallest step that fixes the observed failure**, trying these in order:\n   - a better brief or preloaded skill (the agent lacked knowledge, not access)\n   - a narrower tool form: one MCP tool instead of a whole server, `Bash` behind a hook\n     allowlist instead of open `Bash`\n   - one more tool\n   - a higher `maxTurns`, in steps of about 50%\n   - write access, which also brings `isolation: worktree` and a named file set\n   - a stronger model\n3. **If the need is wider than the job**, the agent's scope was wrong. Split it into a second\n   agent rather than widening the first.\n4. **Re-run the step 4 checklist**, then commit with a message that names the evidence:\n   `agent(\u003Cname>): allow Bash(go test *) — SCOPE_REQUEST in run on #142`. Git history is the\n   scope ledger, so the agent's prompt stays lean.\n\n## Audit\n\nRead each agent in `agents\u002F` and `.claude\u002Fagents\u002F` and run the step 4 checklist on it. Also\nreport what a checklist can't see: no clear reason to exist under rule 1, overlap with another\nagent, or tools never used in practice. Propose cuts, not additions.\n","# Subagent creator\n\nA subagent is a context firewall with a tool budget: worth having when it keeps noise out of\nthe parent, enforces a restriction, or runs independent work in parallel. It is not a persona.\nThis skill grills first and writes the smallest definition that does the job. It never widens\nan agent on its own initiative: scope grows only when the user asks, and only with evidence.\n\nThree modes. Pick from the user's words:\n\n- **create** (default): grill, write, check.\n- **expand `\u003Cname>`**: only when the user asks. Widen the agent by the smallest step.\n- **audit `\u003Cname>|all`**: check existing agents and report what to cut.\n\n## The rules\n\nEach is enforced in the grill, the template, or the step 4 checklist.\n\n1. **Earn it.** A subagent needs one of four reasons: verbose output the parent doesn't need,\n   an enforced tool restriction, self-contained work that returns a summary, or independent\n   parallel work. No reason means it belongs in the main thread, a skill, a hook or a script.\n2. **Code owns control flow.** Fixed steps (lint, push, label, run CI) are scripts or hooks.\n   The agent covers only the open-ended step.\n3. **Smallest box.** An explicit `tools:` allowlist, read-only by default, MCP servers scoped\n   inline, never inherited wholesale. Every visible tool is a decision the agent can get wrong.\n4. **Single writer.** An agent that writes owns its files and runs in `isolation: worktree`.\n   Reviewers, diagnosers and researchers don't write.\n5. **Fresh means blind.** A fresh agent knows only its prompt and the brief. Say what the brief\n   carries. If it really needs the whole conversation, use a fork instead of a custom agent.\n6. **Artifacts, not transcripts.** The agent returns a short, fixed-format result or a file path.\n7. **Bounded.** `maxTurns` is always set. Use a cheaper model only for bounded, checkable work,\n   never for work that must judge its own limits.\n8. **Few hops.** A chain of more than four agent-to-agent handoffs fails. Split by phase, not\n   by domain.\n9. **Enforce, don't ask.** A rule that matters is a hook or a tool restriction, not a sentence\n   in the prompt.\n10. **Ask, don't improvise.** When the agent hits its scope, it stops and returns a\n    `SCOPE_REQUEST`. That request is the only way scope grows.\n\n## Create\n\n### 1. Look before asking\n\nRead the existing agents in `agents\u002F` (if this repo syncs a top-level `agents\u002F` directory) or\n`.claude\u002Fagents\u002F`, plus `~\u002F.claude\u002Fagents\u002F`. Note any that already overlap the request. That is\na fact you look up yourself, never a question for the user.\n\n### 2. Grill\n\nInvoke the `grilling` skill and pass it this agenda. Work the value branch first. If the value\nbranch fails, recommend the alternative and stop: declining to create an agent is a good\noutcome of this skill.\n\n**Value branch**\n- Which of the four reasons applies? Push back on \"it's a specialist\" with no restriction or\n  isolation behind it.\n- Does an existing agent already do 90% of this? If so, widen that agent or branch inside its\n  prompt instead.\n- Is any of this fixed steps that a script or hook could own (rule 2)?\n- Would a skill (reusable knowledge in the parent context) or a fork (needs the conversation)\n  do better?\n\n**Scope branch**\n- The job in one sentence, plus what \"done\" looks like.\n- What the brief hands it, and what it must not assume it knows.\n- The output contract: format, length cap, or the file it writes.\n- Does it write? Default no. If yes, to which files, and confirm worktree isolation.\n- The smallest tool set that finishes the job. For Bash, which commands, and whether a\n  `PreToolUse` hook should hold it to them.\n- Turn budget and model tier.\n- Will it run in parallel with copies of itself? If so, who owns which files?\n\nRecommend the leanest answer on every question. Widening later is cheap through **expand**, so\nstart small. Don't offer extra tools or turns \"just in case\".\n\n### 3. Write\n\nCopy `assets\u002Fagent-template.md` into the agent directory as `\u003Cname>.md` and fill it in. Keep the\nbody under 40 lines. The description says when to delegate *and* when not to, because it is\nwhat the parent reads to decide.\n\n### 4. Check\n\nRead the finished file against this checklist and fix any failure before showing it:\n\n- `tools` is an explicit allowlist: no wildcard, no omission, and nothing the job doesn't use.\n- `maxTurns` is set.\n- Write tools appear only with `isolation: worktree`.\n- Open `Bash` is held by a `PreToolUse` hook, or justified.\n- The body has an `## Output` section with a fixed format or file path.\n- The body tells the agent to reply `SCOPE_REQUEST: \u003Cwhat> — \u003Cwhy>` when blocked.\n- The description says when to delegate and when not to.\n- No template placeholders remain, and the body is under 40 lines.\n\nShow the user the final file and the grill answer behind each field.\n\n## Expand\n\nRun this only when the user asks to widen an agent. Never propose it unprompted, and never\nwiden an agent as a side effect of another task. A `SCOPE_REQUEST` is a report to the user,\nnot permission to act on it.\n\n1. **Get the evidence.** A `SCOPE_REQUEST` the agent returned, a denied tool call, a\n   `maxTurns` cut-off, or a result that was wrong because the agent lacked access. \"It might\n   need it\" is not evidence. Ask for the run, or find it in the transcript.\n2. **Take the smallest step that fixes the observed failure**, trying these in order:\n   - a better brief or preloaded skill (the agent lacked knowledge, not access)\n   - a narrower tool form: one MCP tool instead of a whole server, `Bash` behind a hook\n     allowlist instead of open `Bash`\n   - one more tool\n   - a higher `maxTurns`, in steps of about 50%\n   - write access, which also brings `isolation: worktree` and a named file set\n   - a stronger model\n3. **If the need is wider than the job**, the agent's scope was wrong. Split it into a second\n   agent rather than widening the first.\n4. **Re-run the step 4 checklist**, then commit with a message that names the evidence:\n   `agent(\u003Cname>): allow Bash(go test *) — SCOPE_REQUEST in run on #142`. Git history is the\n   scope ledger, so the agent's prompt stays lean.\n\n## Audit\n\nRead each agent in `agents\u002F` and `.claude\u002Fagents\u002F` and run the step 4 checklist on it. Also\nreport what a checklist can't see: no clear reason to exist under rule 1, overlap with another\nagent, or tools never used in practice. Propose cuts, not additions.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fmeta\u002Fsubagent-creator","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":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill subagent-creator",{"tool":59,"command":60},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill subagent-creator",{"tool":62,"command":63},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill subagent-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fsubagent-creator\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"assets\u002Fagent-template.md","ASSET","资产文件",1236,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fsubagent-creator\u002Fassets\u002Fagent-template.md",[74,100,126,153,175,194],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":40},"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",[],[81,82,83,84,38,85,86,87,88,89,90,91,92,93,94,95,96,97,98,27,99],"to tickets","tickets","github","run","batch","manifest","plan","repo","command","worktrees","task","signatures","feature","plans","as","cut","ticket","true","new",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":111,"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",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[112,31,113,114,88,115,89,22,116,117,118,119,120,95,121,29,122,123,98,124,27,125,23,99],"to seams","repos","file","prompt","schema","build","but","either","record","records","block","interface","can","neither",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":137,"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",[132],{"categoryNo":133,"categoryName":134,"taxonomyType":135,"taxonomyTypeDesc":136},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[138,139,140,87,141,142,143,144,145,146,93,95,97,147,148,82,149,150,151,98,152,23],"roadmap","to roadmap","doc","board","never","later","next","self","ideas","via","card","now","about","re","features",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"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",[159],{"categoryNo":133,"categoryName":134,"taxonomyType":135,"taxonomyTypeDesc":136},[161,162,163,164,87,165,166,167,93,95,168,169,82,170,171,172,151,98,173,174],"to prd","prd","report","state","ask","say","delivery","line","problem","spine","multi","interviews","which","codebase",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"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",[],[87,182,183,38,114,184,185,186,187,188,22,116,189,190,191,93,94,192,98,27,193,99],"to plan","pr","ports","glossary","branch","short","overview","only","project","contract","types","\u003Cslug>",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":40},"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",[],[201,97,202,203,204,205,206,207,85,114,208,209,22,210,138,211,212,213,214,146,93,215,216,27,217,218,24,23,99],"tracker","ticket tracker","review","cli","current state","update","issues","gh","pick","ready","up","show","done","backlog","progress","move","fixes","labels"]