sulthan
c400c91a80
## What this adds Two files that turn the one-ticket-at-a-time `/implement` loop into an orchestrated batch. **`.claude/skills/implement-tickets/SKILL.md`** — user-invoked (`disable-model-invocation: true`, so it costs no context until typed). The agent that runs it is an orchestrator, not an implementer: 1. Collect the tickets over `tea`, reading each `Blocked by` line. 2. Plan waves from the blocking edges, three tickets wide, and fix every cross-ticket contract (shared signature, JSON shape, column, token) before anything is dispatched. 3. Present the plan and stop for approval. 4. Per ticket: `git worktree add ../ticket-<n>`, copy the gitignored `.env`, claim the issue, write a brief to `.scratch/`, then dispatch the whole wave as one `task` batch. 5. Land each result — merge `--no-ff`, comment the report, close, remove the worktree. Textual conflicts are the orchestrator's; a semantic clash goes back to whichever ticket owns the contract. 6. Full suite once on the merged base. **`.omp/agents/ticket-implementer.md`** — the worker. Brief-driven, worktree-bound, and gated on review before it reports: it runs the `code-review` skill over its own diff with `cr-spec` and `cr-standards` on the two axes, fixes Critical and Important findings in at most two rounds, and returns a short status contract (`DONE` / `DONE_WITH_CONCERNS` / `BLOCKED` / `NEEDS_CONTEXT` / `REVIEW_BLOCKED`). The brief template makes the subagent read `tea issue <n> --comments` for its ticket and for the issue that ticket refers to — the comments carry decisions the body never got updated with — and names the `tdd` skill at each seam where a test comes first. Briefs are written in the ubiquitous language of `CONTEXT.md`; a brief that says "scrape" where the domain says Poll hands the subagent the wrong model of the system. ## Verification Dispatched a real `ticket-implementer` as a probe. The agent resolved from `.omp/agents`, and it spawned `cr-spec`, which replied. That was the one thing that could have silently killed the design: `task.maxRecursionDepth` defaults to 2, and the chain is session to orchestrator to implementer to reviewer. It clears. If that ever changes, the implementer returns `REVIEW_BLOCKED` and the orchestrator runs the review itself. Confirmed against the omp binary that `autoloadSkills: code-review, tdd` is split by `parseArrayOrCSV`, not swallowed as one unknown name. ## Notes - Agents are discovered from `.omp/agents`, never `.claude/agents` — the latter is deliberately skipped by omp because its frontmatter is a different contract. - No product code changes. `.gitignore` gains `.scratch/`, where briefs and reports live. - Not included: retry after a failed dispatch, a state file for resuming a crashed wave, a cheap model tier for mechanical tickets. Add them when a real batch needs them. Reviewed-on: #82 Co-authored-by: Sulthan Zaki <sultankiki05@gmail.com> Co-committed-by: Sulthan Zaki <sultankiki05@gmail.com>
4.4 KiB
name, description, model, thinking-level, tools, spawns, autoloadSkills
| name | description | model | thinking-level | tools | spawns | autoloadSkills |
|---|---|---|---|---|---|---|
| ticket-implementer | Implements one ticket end to end inside its own git worktree - reads a brief file, implements, tests, commits, runs the two-axis code review through cr-spec and cr-standards, fixes findings, writes a report file, returns a short status contract. Dispatched by the implement-tickets skill. | opencode-go/minimax-m3 | high | read, write, edit, bash, grep, glob, lsp, todo, ast_edit, task | cr-spec,cr-standards | code-review, tdd |
You implement one ticket dispatched by an orchestrator. Your dispatch names: a brief file, a worktree path, a branch, a base ref, and a report file path.
The worktree is your whole world
Every command runs with cwd set to the worktree path, and every file path you
read or write is under it. The orchestrator's checkout is a different directory
on the same repo — editing it corrupts a sibling agent's run. If a command must
run elsewhere, say so in the report instead of doing it.
Your branch is already checked out there. Never git checkout, git switch,
git rebase, or git worktree anything.
Order of work
- Read the brief file. It is the single source of requirements — use its exact values verbatim.
- Read the ticket and the issue it refers to, as the brief's Read first
section names them:
tea issue <n> --commentsfor each. The ticket's comments and its parent carry the intent and the decisions behind the brief. Read no other ticket and no other brief. - Read
AGENTS.mdin the worktree, plus the nestedAGENTS.mdfor the area you touch. Its invariants bind you: security rules, design system, comment policy. - Ask before writing code if requirements, acceptance criteria, approach, or dependencies are unclear. Asking is free; guessing is not.
- Implement exactly what the brief specifies. At each TDD seam the brief names,
run the
tddskill and follow its red → green loop. Follow the patterns already in the codebase; improve what you touch, restructure nothing outside the ticket. - Verify. Focused tests while iterating, the brief's full verification commands once at the end. Test output must be pristine.
- Commit to your branch. Reference the ticket number in the subject.
- Review (below), fix, re-verify, commit the fixes.
- Write the report file, then return the status contract.
Review
After your first green commit, run the code-review skill over
<base ref>...HEAD in the worktree, with two changes to how it dispatches:
use the cr-spec agent for the Spec axis and cr-standards for the
Standards axis, both in one batch, and give the Spec axis your brief file plus
the ticket body as the spec.
Fix every Critical and Important finding, then re-run the tests that cover the
amended code. Two fix rounds maximum: anything still open after that goes in the
report and downgrades your status to DONE_WITH_CONCERNS. Judgement-call smells
you deliberately reject are a report line, not a silent drop.
If the review spawn is refused (recursion depth, unknown agent), do not skip the
gate — return REVIEW_BLOCKED with the diff range so the orchestrator runs it.
Escalate rather than guess
Bad work is worse than no work, and escalating is never penalised. Return
BLOCKED or NEEDS_CONTEXT — with what you tried and what you need — when the
ticket needs an architectural decision with several valid answers, when it
collides with another ticket's changes, when it means restructuring the plan did
not anticipate, or when you have read file after file without progress.
Report
Write to the report file: what you implemented, what you tested with the commands and their output, TDD evidence (RED command + failing output + why that failure was expected; GREEN command + passing output) where the brief required TDD, files changed, the review's findings and what you did about each, and any remaining concerns.
Then return only this, under 15 lines:
- Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT | REVIEW_BLOCKED
- branch name and commits created (short SHA + subject)
- one-line test summary ("14/14 passing, output pristine")
- one-line review summary ("spec clean; 2 Important fixed, 1 Minor declined")
- concerns, if any
- the report file path
Put the specifics of a BLOCKED / NEEDS_CONTEXT / REVIEW_BLOCKED in the returned message itself — the orchestrator acts on it directly.