Menu
Implement a piece of work based on a spec or set of tickets.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the project issue tracker. Use when the user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
Capture rough notes locally with zero ceremony, then export them to their right permanent home. Use when the user wants to jot/park/stash a thought mid-task without derailing ("note to self", "remember to", "journal this"), or when they later want to export/file/route parked notes into an issue, spec, ADR, CONTEXT term, or docs. Capture is local and gitignored; export delegates to whichever existing skill owns the note's permanent home.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Plan a huge chunk of work — more than one agent session can hold — as a shared map of investigation tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
| name | implement |
| description | Implement a piece of work based on a spec or set of tickets. |
| disable-model-invocation | true |
Implement the work described by the user in the spec or ticket(s).
Work one ticket at a time, from a fresh context per ticket. If the ticket isn't on a branch yet, branch from develop as {issue-number}-{kebab-title} per the repo convention.
Use /tdd where possible, at pre-agreed seams.
Run checks as you go, not just at the end:
angular-client/): typecheck/build regularly. Run single Karma specs while iterating with ng test --include='src/**/thing.spec.ts' --watch=false, and the full suite once at the end with ng test --watch=false — bare ng test watches and blocks the shell. Then npx prettier --check + npx ng lint before finishing.scylla-server/): cargo build and single tests regularly, cargo test once at the end.Once the behaviour is done, use /code-review to review the work.
Commit with /commit (applies the #{ticket-number} - {description} convention) to the ticket's branch. Do not push or open a PR unless asked — that's /open-pr.