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>
5.1 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| plan-tickets | Plan a batch of tickets and write the briefs for its next wave: read the tracker, decide waves and contracts, get the plan approved. | true |
Plan tickets
You produce the two artifacts the implement-tickets skill runs on: a plan
file and one brief per ticket in the next wave. You write no ticket code
and create no worktrees — that is the runner's half.
Ticket source and tracker conventions: docs/agents/issue-tracker.md. tea usage: skill gitea.
Called twice in a batch's life, at least: once to open it, then again after each
wave lands, because a later wave's briefs may need what the last one changed. On
a re-entry, read the existing .scratch/<batch-slug>/plan.md first and plan only
the next unlanded wave — the waves and contracts already approved there stand
unless the landed wave proved one wrong.
1. Collect the tickets
The user's argument is the selector: issue numbers, a label, a parent issue, or
nothing. With nothing, take the open issues labelled ready-for-agent.
Fetch each with tea issue <n> --comments, and read the whole body —
acceptance criteria and the Blocked by line are what the rest of this skill
runs on. A ticket whose blockers are still open is out of this batch unless a
blocker is also in it. Read the issue each ticket refers to, its parent or spec,
the same way: nothing on the implementation path reads the tracker after you —
only cr-spec does, at review time — so a decision that lives in a comment
reaches the implementer only if you carry it into the brief.
2. Plan the batch
Explore enough of the codebase to write briefs a fresh context can act on: the
files each ticket lands in, the patterns it must follow, the AGENTS.md
invariants it touches.
Then decide three things:
- Waves. Blocking edges set the order; tickets with no open blocker inside the batch share a wave. Cap each wave at 3 concurrent tickets unless the user set another width.
- Contracts. Two tickets in one wave that meet at a function signature, a JSON shape, a table column, or a token name: you decide the shape now and write the identical wording into both briefs. A contract left for the subagents to negotiate is a merge conflict you scheduled.
- Splits. A ticket too big for one fresh context window goes into the wave as two briefs, or back to the user.
3. Write the artifacts
Pick a <batch-slug> — short, from what the batch is about — and write
.scratch/<batch-slug>/plan.md. It is the handoff: the runner is a fresh context
that reads this and nothing of your reasoning.
Batch
Base branch. The branch every worktree forks from and merges back into.
Waves. A table: wave number, ticket number, title, brief path, and status —
planned | dispatched | landed | handed back. Every ticket in the batch,
including waves not briefed yet.
Contracts. Each cross-ticket contract verbatim, naming both ticket numbers.
Assumptions. What you had to assume, and what the user corrected at approval.
Then write a brief per ticket in the next wave to
.scratch/<batch-slug>/t<n>-brief.md, using the template below, 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.