mangaBookmark/.claude/skills/implement-tickets/SKILL.md

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.