| name | implement-task |
| description | Execute a product-task spec one leaf subtask per run — [agent] subtasks via the project skills, [human] subtasks handed off to the developer. |
| disable-model-invocation | true |
Implement task
Work through a spec produced by grill-the-task / to-spec, one subtask per run. The spec is the state
machine: each run starts a fresh session, picks up where the spec says work stopped, executes a single
subtask, updates the spec, and stops so the developer can verify and commit. Any colleague can resume the
task from the branch alone.
Invocation
/implement-task — no arguments, the usual case: infer the spec (and the current subtask, from a
-step-<N> branch) from the branch name, per the Branch model below. Execute the next eligible subtask
(Step 3)./implement-task 4 — a specific subtask, out of order. Pending questions still refuse the run;
unchecked dependencies are pointed out and need the developer's explicit confirmation to proceed./implement-task 2.3 — when a subtask's own spec has a multi-step breakdown, address its leaf steps
with dotted numbers: step 3 inside subtask 2's sub-spec (subtasks/02-<slug>/spec.md). The sub-spec's own
breakdown is the checklist for that subtask; its header status is maintained like a spec's.- An explicit task dir as the first argument (e.g.
/implement-task 3219-cross-chain-views 4) overrides
branch inference — needed when not on the feature branch yet.
The unit of one run is always a leaf: "next eligible subtask" descends — if the next subtask has its
own multi-step sub-spec, execute the next eligible leaf step inside it (one step, then stop).
Branch model
One feature branch holds the whole product task; it lands in main as one PR when the task is done.
Within it: a big subtask (several commits) gets its own sub-branch and a PR into the feature branch; a simple
subtask is a single commit directly on the feature branch. Remind the developer of this when a subtask
starts, but never commit, push, or open PRs yourself — the developer reviews the diff and commits between
runs.
PR timing (developer's action — prompt, don't do): a draft PR opens as soon as the spec is the branch's
first commit (feature branch → main; a big subtask's sub-branch → feature branch, with its sub-spec as
the first commit) and flips to ready for review when its breakdown's last box is checked. Nudge accordingly:
on a first run with no PR yet, suggest opening the draft; when checking off the final subtask (or a big
subtask's final leaf step), suggest finalizing it via the create-pr skill (finalize-draft mode: real
description from the diff, labels, then ready for review).
Branch names carry the addressing. The feature branch is issue-<number> (e.g. issue-3219); a big
subtask's sub-branch adds a -step-<N> postfix (e.g. issue-3219-step-2). An ad-hoc spec's branch is its
task-dir slug (.agents/tasks/<slug>/ → branch <slug>). Dash postfixes, not slashes — git forbids
X and X/… coexisting. The names are fully mechanical, which is what lets the skill construct branches
itself and infer the spec (and the current subtask) with no arguments: issue-<n> matches the task dir by
issue number, any other branch matches by exact dir name.
Workflow
Step 1 — Load state
Resolve the spec per the Invocation section (branch inference by default, explicit task dir wins); if
neither yields a match in .agents/tasks/, ask. Read the main spec — and the target subtask's
subtasks/<NN>-<slug>/spec.md, when a -step-<N> branch or a dotted target selects one — plus
.agents/rules/delegation.mdc. If the header has no feature branch yet, construct it from the convention
above (issue-<number>), confirm with the developer, create it, and record it in the header.
Step 2 — Reconcile the previous handoff
If the previous subtask in the breakdown is [human] and still unchecked, ask the developer whether it's
done before doing anything else — check it off if so, stop if it's still in progress (the order exists for a
reason; don't leapfrog a pending style step unless the developer explicitly says the next subtask is
independent).
Step 3 — Pick the next subtask
If the invocation named a subtask or leaf step, that's the pick (with the guardrails from the Invocation
section). Otherwise: the first unchecked subtask whose dependencies are all checked and whose listed
questions are all resolved or waived, descending into sub-specs to a leaf step. Then:
- All remaining subtasks blocked by
pending questions → tell the developer which questions block what,
and suggest running to-spec to harvest Slack answers. Stop.
- Next subtask is
[human] → hand off: state what needs doing, link the Figma node, note that the
scaffold's TODO (design): markers are the worklist. Stop.
- Next subtask has only a
brief.md, no spec.md yet → it isn't scoped; tell the developer to run
grill-the-task in subtask mode for it (it writes the folder's spec.md from its brief.md). Stop.
- Next subtask is
[agent] → proceed.
Step 4 — Execute (one subtask only)
Do the work, composing the project skills wherever one applies (add-api-resource, add-env-var,
add-new-page, deploy-demo, …) and staying inside the delegation boundary — scaffolds get placeholder
presentation and TODO (design): markers, never final styling. Follow the sub-spec if the subtask has one.
The spec should already contain the executing skill's inputs — the grilling session runs each skill's
interview up front, so skip any of the skill's questions the spec answers and run uninterrupted. If an
input is genuinely missing, ask the developer and backfill the answer into the spec before proceeding.
Write the unit tests and Playwright scaffolds the standing testing policy assigns to this subtask (test the
behavior that matters, not the obvious — per .agents/rules/tests-unit.mdc).
Step 5 — Verify
Run every code-quality check the repo defines (per .agents/rules/code-quality.mdc — run all of them, not
only the ones you remember) plus the relevant unit tests. Intentional scaffold TODOs may keep ESLint red
in the same way the add-new-page skill documents — say so explicitly rather than chasing green.
Step 6 — Update the spec and stop
Check the box for what you did, with a one-line note (files/skills involved) — never a multi-line
changelog; git and the PR carry the detail, and any durable decision (a new dependency, an architectural
choice) is folded into the relevant spec section instead.
Keep both checklist levels in sync when the subtask has its own sub-spec:
- Check the leaf step in the sub-spec's breakdown; set the sub-spec's header
Status to in progress
on its first step and done when its last box is checked.
- When a sub-spec goes
done, check its subtask line in the main index too.
- Set the main header
Status to in progress on the first executed subtask and done when the
index's last box is checked.
The main index is what "done" and draft-PR finalization key off, so never leave it trailing a completed
sub-spec. Then summarize the result and end the run — verification of the diff, the commit, and the next
implement-task invocation belong to the developer.
