sulthan
faa80c41ea
Adds `.claude/skills/plan-tickets/SKILL.md` and trims `implement-tickets` to dispatch-only, with the matching `.omp/agents/ticket-implementer.md` update. Docs/skills only — no backend, userscript, or web changes. Reviewed-on: #162 Co-authored-by: Sulthan Zaki <sultankiki05@gmail.com> Co-committed-by: Sulthan Zaki <sultankiki05@gmail.com>
78 lines
3.6 KiB
Markdown
78 lines
3.6 KiB
Markdown
---
|
|
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.
|