| 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"] |
Track Work
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.
Break down
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.
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).
Track status
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" list
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" show <id>
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" next <id>
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.
Rules
- Right-size ruthlessly. A ticket that can't be reviewed in one sitting is
too big — split it.
- Every ticket traces to the plan. No ticket that the plan-feature output
doesn't justify; flag scope creep to the user.
- Keep status honest. Only mark a step
done when it truly is — the ship
umbrella and next depend on it.
- Record cross-ticket decisions with memory-keeper so they outlive this session.
Finish
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.