Implement a batch of tickets through per-ticket subagents #82

2026-08-11T10:07:33+07:00

sulthan commented

2026-08-11 10:07:33 +07:00

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:

Collect the tickets over tea, reading each Blocked by line.
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.
Present the plan and stop for approval.
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.
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.
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.

## 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.

sulthan added 1 commit 2026-08-11 10:07:34 +07:00

Implement a batch of tickets through per-ticket subagents c728baae6d

The manual loop was one /implement invocation per ticket, all of it
running in the session the human was talking to. This adds an
orchestration layer instead: the invoked agent plans and dispatches,
and every line of ticket code is written by a subagent in its own
git worktree.

.claude/skills/implement-tickets is the orchestrator — collect the
tickets over tea, group them into waves by their blocking edges (three
wide), fix the cross-ticket contracts up front, gate on the human's
approval, then dispatch a wave as one task batch and land it: merge,
comment, close, remove the worktree.

.omp/agents/ticket-implementer is the worker. It reads a brief, reads
the ticket and its parent for intent, runs the tdd skill at the seams
the brief names, commits, then gates itself on the two-axis review
through cr-spec and cr-standards before reporting a short status.

Agents are discovered from .omp/agents, never .claude/agents. Verified
by dispatch that the agent resolves and that it can spawn cr-spec —
the orchestrator/implementer/reviewer chain clears the recursion cap.

sulthan merged commit c400c91a80 into main

2026-08-11 10:08:10 +07:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sulthan/mangaBookmark#82