3.6 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| implement-tickets | Run a planned wave of tickets: one implementer subagent per ticket in its own worktree, then land, merge and close what comes back. | true |
Implement tickets
You are the orchestrator. You dispatch, land results, and talk to the
tracker. You do not write the implementation — every line of ticket code is
written by a ticket-implementer subagent in its own git worktree. Reach for the
editor yourself only for a merge conflict resolution.
Ticket source and tracker conventions: docs/agents/issue-tracker.md. tea usage: skill gitea.
0. Load the plan
Your argument is the batch slug. Read .scratch/<batch-slug>/plan.md — it gives
the base branch, the waves, the contracts, and each ticket's brief path and
status. Run the earliest wave that is not landed.
The briefs are the requirements and they are already approved: read each one you
are about to dispatch, but do not rewrite it, and do not fetch the tickets from
the tracker to second-guess it. A brief that is wrong or thin is a plan-tickets
problem — say so and stop, rather than patching it here.
No plan file, or no briefs for the next wave: run plan-tickets first. That
skill owns wave membership, contracts, and every brief.
1. Dispatch the wave
Per ticket, before dispatch:
git worktree add ../ticket-<n> -b ticket/<n>-<slug> <base> # base = the plan's base branch, checked out here
cp .env ../ticket-<n>/ 2>/dev/null # gitignored, worktrees do not get it
tea issue edit <n> --add-assignees <your gitea username> # tea login list has it
Then dispatch the whole wave in one task batch, every item on the
ticket-implementer agent. Each dispatch names: the absolute brief path, the
worktree path, the branch, the base ref, and the report path
.scratch/<batch-slug>/t<n>-report.md. Mark each ticket dispatched in the plan
file.
2. Land the wave
The wave is landed when every ticket in it is closed, reverted, or handed back to the user. Per returned ticket:
| Status | What you do |
|---|---|
DONE |
merge, comment, close |
DONE_WITH_CONCERNS |
merge, comment the concerns, close only if you judge them non-blocking — otherwise leave open and tell the user |
BLOCKED / NEEDS_CONTEXT |
supply what is missing and re-dispatch, or hand back to the user with the specifics. Never implement it yourself |
REVIEW_BLOCKED |
run code-review over the branch yourself (cr-spec + cr-standards), then treat the outcome as the statuses above |
Merge from your own checkout: git merge --no-ff ticket/<n>-<slug>. A textual
conflict is yours to resolve (resolving-merge-conflicts). A semantic
clash — both sides green apart, wrong together — goes back to whichever ticket
owns the contract, as a re-dispatch with the collision described.
Then tea comment <n> "<the report summary>", tea issue close <n>, and
git worktree remove ../ticket-<n>. Keep the report file, and mark the ticket
landed or handed back in the plan file.
3. Hand back or close the batch
Waves left in the plan: stop and say which wave is next. Its briefs are written
by plan-tickets against the base you just changed — that is why they were not
written up front, and why you do not write them.
Last wave landed: run the full suite once on the merged base, and report a line per ticket with its status, commits, and open concerns, plus anything still assigned or open on the tracker. A red suite after every ticket went green is an interaction bug — diagnose it, name the two tickets, and fix it or hand it back with both named.