메뉴
Break a plan into small, independently shippable tickets and track their status across the pipeline. Use when a feature is bigger than one change, when the user wants a task breakdown or a status view, or after plan-feature produces a plan that needs splitting.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Run a bounded change → verify → fix cycle until an objective check passes (tests green, lint clean, build/type-check ok) or a hard iteration cap is hit. Use for any task that needs repeated attempts against a verifiable signal instead of a single one-shot edit.
Review code for behavior-preserving simplification — collapse duplication, remove dead code and over-engineering, cut verbose patterns down to idiomatic ones. Use when code is longer or more complex than it needs to be, or the user asks to simplify, shorten, refactor, or clean up.
Implement a planned ticket on its own branch using test-first development, updating docs as part of the change, looping change→verify→fix until the suite is green. Use when a ticket has a plan and is ready to build, or the user says "implement X" / "build the ticket" / "make it pass".
Use to store durable context (decisions, facts, preferences, todos, summaries) and to recall or reply from it across sessions. Load when something worth remembering appears, or when the user asks what you were doing, what was decided, or to continue prior work.
Choose the right model and effort per task phase and apply it when dispatching subagents — strong model + high effort for planning and review, a cheaper model + lower effort for mechanical execution. Use when a task splits into plan / execute / review phases or you're spawning subagents.
Push a reviewed ticket branch and open a pull request with a structured title and body, after review-changes has passed. Use when a ticket is reviewed and ready to ship, or the user says "open a PR" / "create the pull request". Stops at opening the PR — never merges.
| name | track-work |
| description | Break a plan into small, independently shippable tickets and track their status across the pipeline. Use when a feature is bigger than one change, when the user wants a task breakdown or a status view, or after plan-feature produces a plan that needs splitting. |
| model | sonnet |
| effort | medium |
| allowed-tools | ["Read","Bash"] |
| argument-hint | [feature or ticket id] |
| triggers | ["break this down","create tickets","what's the status","track this","split into tasks"] |
| tags | ["tickets","tracking","breakdown","pipeline"] |
Keep delivery organized: split work into right-sized tickets and know what state
each is in. This is pipeline step 2 (plan → track → implement → review → pr).
State lives in the happy pipeline store and mirrors into memory, so it survives
sessions.
A good ticket is one reviewable change — independently shippable, testable on its own, roughly one PR. If a piece can't be verified alone or would be a huge diff, split it further.
# one ticket per shippable unit (each prints its id + branch)
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" new "Wishlist data model" --type task
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" new "Wishlist API endpoints" --type task
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" new "Wishlist UI" --type task
Order them by dependency and say which can proceed in parallel (disjoint files) vs. sequentially (shared files).
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" list # every ticket + per-step progress
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" show <id> # one ticket in detail
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" next <id> # the next incomplete step
Update a step as work moves (the ticket's overall status rolls up automatically):
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <id> track done
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <id> implement in_progress --note "endpoints wired"
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" note <id> "gotcha: rate-limit shares the login bucket"
Steps: plan, track, implement, review, pr.
Statuses: todo, in_progress, blocked, done, failed.
done when it truly is — the ship
umbrella and next depend on it.Show the ticket list with progress and point at the next action: implement the first ready ticket, or ship to run the pipeline for one.