| name | kanmer-auto |
| description | Autonomously clear a set of Kanmer tickets — target an area or a group (epic/horizon), and drive every eligible ticket through its profile's pipeline up to a specified point, orchestrating parallel subagents in conflict-free waves and respecting the document gates. Use when the user says "clear the API area", "work through the backlog", "burn down UI up to review", "do all the tickets in <area>", "clear HZN-003", "work through 0.3.3", "finish this epic". DO NOT USE FOR a single ticket — use the phase skills directly. |
Clearing an area autonomously
kanmer-auto is orchestration, not new mechanics: each ticket still goes
through the phase skills' procedures exactly as written — this skill decides
which tickets, in what order, and how many at once.
1. Gather and scope
get_status, then list_items for the target — area for a subsystem,
group for an epic or a horizon (list_items group: "HZN-003"). Board order
is the human's ordering — respect it. Group membership is derived in id order
and is not a priority, so a group scopes the roster and nothing else.
Filters are AND, so group + area narrows to one subsystem's share of a
release.
Use list_items, not get_group, to build the roster: get_group's derived
members carry only id/title/stage, and the drop rules below need taken and
blocked, while §3 needs profile.get_group_doc for the group's shared context if you scoped by one — the
constraint binding the batch is written there once and applies to every
member.- Drop: archived,
blocked: true, and tickets taken by someone else
(coordinate, don't force).
- Parse the target point from the request: "up to review" means each
ticket stops once its PR is open and the ticket sits in the review stage;
the default is full closeout (merge permitting — if merging is the human's
call, tickets park in review and you say so). Resolve stage names against
list_board.
- Gates are hard, and per-ticket. Call
get_doc_gates <id> for every ticket
in the roster and drive that ticket's boundaries — do not assume a common
pipeline. Profiles differ in how many stages they walk and which documents
they owe, so reachable on that call is the roster's routing table. Driving
every ticket through one pipeline is the mistake this warning exists to
prevent.
- One gated boundary per move. A lane advances a ticket one stage at a time;
a move crossing two gated boundaries is refused. Partition the roster by
profile so lanes with genuinely different pipeline lengths do not block each
other.
- Set
docs_todo on tickets that need a governing doc written so they are not
stranded at the first gate.
- Tell the user the roster before starting: what you scoped by (naming the
group, if you used one), which tickets, target point, what was skipped and
why. A roster resolved from a group is worth showing back before anything
starts — it is the one step the user cannot check by reading the request.
2. Wave 0 — research everything in parallel
Research is read-only: no branches, no worktrees, no conflicts.
Run one subagent per ticket concurrently (use your host's subagent/task
mechanism), each following the kanmer-research skill for its ticket.
Tickets whose research surfaces user-only questions get parked and reported
— don't guess on the user's behalf.
This is not only a wave-0 concern: a question can surface at any point, and a
lane that hits one stops there and is reported as parked-on-a-question, named
and quoted — never rolled into the generic failure bucket. The operator can
answer a question in seconds; they cannot answer one they were never shown. The
gates enforce some of the stopping — get_doc_gates says which boundaries
this ticket's profile actually has, and they are not the same for every profile —
but the merge is outside the engine entirely, so a lane can land code on a
question the operator never saw. Reporting it is therefore this skill's job, not
the engine's.
3. Partition into conflict-free lanes
Compare the file tables in each ticket's files document:
- Tickets touching disjoint files → different lanes, safe in parallel.
- Tickets with overlapping files → the same lane, run serially.
- A
blocks edge forces ordering regardless of lanes: the blocker finishes
(to the target point) before the blocked ticket starts.
Cap concurrency at ~3 lanes — enough to matter, few enough that rebases and
reviews stay manageable.
4. Execute the waves
Every lane works in its own worktree, and none of them touches
.worktrees/kanmer — in a repo set up through the GUI that is the board's own
worktree, on the board branch, with MCP rooted in it. It is never a lane's
worktree, never a rebase target, and never cleaned up. With ~3 lanes running git
surgery in parallel this is the invariant with the most chances to be broken.
Each lane's current ticket runs in its own subagent: kanmer-plan →
kanmer-execute (own worktree .worktrees/<id>, own branch) →
kanmer-review (which merges on pass) → kanmer-verify (validate on merged
main, write proof) → kanmer-closeout — each phase only as far as the target
point allows. After anything merges to main, lanes still in flight rebase
before opening their PRs:
git fetch origin && git rebase origin/main
A ticket that fails (tests won't pass, plan turns out wrong, rebase
conflicts beyond mechanical resolution) doesn't sink the run: release it,
append what happened to its checklist progress notes, move it back to the
appropriate stage, and continue the lane with the next ticket.
If your host has no subagent mechanism, run the same waves sequentially —
the lane partition still tells you the safe order.
5. Report
Finish with a standup-style summary: cleared (closed out),
at target (parked at the requested point, e.g. awaiting merge),
parked (user-only questions — quote them, with the ticket id and the
recommendation, so the operator can answer inline), skipped
(blocked / taken / failed, with reasons). Every ticket in the roster
appears in exactly one list — silent drops are how autonomous runs lose
trust.
No single successor — this skill is the hand-off. It drives the phase
skills in order for each ticket in its roster:
kanmer-research → -plan → -execute → -review → -verify → -closeout
stopping each ticket at the requested target point, and stopping the whole run
at any question only the operator can answer. When the roster is exhausted,
control returns to the operator with the four-list report above.
