Implement
Follows the aiwork-protocol skill. Don't enter plan mode — the ticket is the plan. One work item, one pass, this session; for a whole spec with a ticket graph use /implement-spec.
Resolve input
$ARGUMENTS is one of:
- Ticket path: use directly. Verify the ticket is
status: readyand everyblocked_byticket isstatus: done; if not, warn and ask. - Inline description: if trivial (fits one session, obvious approach), treat it as the work item. If non-trivial, stop and suggest
/to-spec. - Spec/PRD or task folder path: stop and suggest
/implement-spec.
Do
- Set ticket
status: in-progress(if working from a ticket). - Implement. Use
/tddwhere possible, at the seams recorded in the spec's Testing Decisions section. - Tidy the diff yourself — naming, duplication, dead scaffolding. Not
/simplify: its reviewers would rediscover context you already have. Skip for a mechanical edit. - Run the project's check command (see its scripts). Green before anything below.
- Run
/verify <ticket-path>so it verifies the ticket's acceptance criteria, not just the diff. Check off- [ ]→- [x]for each criterion it passed. - Run
/code-review low --fix. Re-run the checks if it changed code. - Set ticket
status: doneandverified:to the passes that ran (checks,behaviour,review), then commit. Do not ask. Report what was done and anything left open.
Stopping is hooked: the plugin's verified-gate holds the turn when a ticket claims done without an on-app pass (behaviour, ux or human in verified:) or with unticked acceptance criteria. Set the frontmatter because the passes ran, never to get past the hook. If a pass genuinely cannot run, leave the ticket in-progress and say why in implementation-notes.md. See /aiwork:implement-spec for details.
Record a note in the task folder's implementation-notes.md per aiwork-protocol when the reader must act on it: work only a human can finish, anything left unverified, a spec ambiguity you resolved, a deliberate deviation. A few sentences, never a log of what you built. Nothing to note is the normal case.