---
name: implement-tickets
description: "Run a planned wave of tickets: one implementer subagent per ticket in its own worktree, then land, merge and close what comes back."
disable-model-invocation: 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:

```bash
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.