sulthan
d168cf1ad0
Measured on this repo, graphify cost more than it returned. `graphify query` answers with a keyword-seeded BFS neighbourhood, not a location: asking where CORS origin reflection lives returned 73 nodes, mostly api_test.go helpers plus an unrelated golang-performance doc section matched on the word "reflection", and never named httpmw/middleware.go:135 or main.go:121 — which grep gives in 40ms. `graphify explain` on a known symbol is sound but duplicates what the LSP already answers against live files. Against that, the PreToolUse hooks injected a "run graphify query first" paragraph on every grep and every source read, the map cost 685k input tokens across five builds, and graph.json plus graph.html carried 3.4MB through 11 commits of churn. AGENTS.md is the better orientation artifact: it holds the CDP and clock findings, the adapter list, and the security invariants, none of which an AST graph can derive. Removes the committed map, the AGENTS.md rules block, the .gitignore entries, both hooks, and the stale `graphify query` instruction in the implement-tickets skill. The CLI, its skill directory, and the post-commit / post-checkout git hooks were uninstalled outside the tree.
134 lines
5.6 KiB
Markdown
134 lines
5.6 KiB
Markdown
---
|
|
name: implement-tickets
|
|
description: "Orchestrate a batch of tickets: plan the briefs, then hand each ticket to its own implementer subagent in its own worktree."
|
|
disable-model-invocation: true
|
|
---
|
|
|
|
# Implement tickets
|
|
|
|
You are the **orchestrator**. You write briefs, 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 `tea` usage: `docs/agents/issue-tracker.md`.
|
|
|
|
## 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.
|
|
|
|
## 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. Get the plan approved
|
|
|
|
Present, and stop:
|
|
|
|
- the wave list, and for each ticket: number, title, one-line brief summary,
|
|
the files or areas it will touch, its verification commands
|
|
- every cross-ticket contract, verbatim as it will appear in the briefs
|
|
- anything you had to assume
|
|
|
|
Wait for approval. Apply the user's edits to the plan, do not relitigate them.
|
|
|
|
## 4. Run a wave
|
|
|
|
Per ticket, before dispatch:
|
|
|
|
```bash
|
|
git worktree add ../ticket-<n> -b ticket/<n>-<slug> <base> # base = the branch you are on
|
|
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
|
|
```
|
|
|
|
Write the brief 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.
|
|
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`.
|
|
|
|
<brief-template>
|
|
|
|
# Ticket #<n> — <title>
|
|
|
|
**Read first.** `tea issue <n> --comments` for this ticket, then the issue it
|
|
refers to — the parent or spec — the same way. The comments carry decisions the
|
|
body never got updated with. This brief stays the requirements; those two reads
|
|
are the intent behind them.
|
|
|
|
**Goal.** The end-to-end behaviour this ticket makes work, from the user's side.
|
|
|
|
**Acceptance criteria.** Verbatim from the ticket.
|
|
|
|
**Contract.** The exact shared signatures / shapes / names this ticket must
|
|
implement or consume, and which sibling ticket is on the other end. Omit when
|
|
the ticket touches nothing shared.
|
|
|
|
**Where it lands.** The files and packages, and the existing pattern to follow
|
|
in each.
|
|
|
|
**Binding invariants.** The `AGENTS.md` rules this change can break — name them.
|
|
|
|
**TDD seams.** Where a test comes first — run the `tdd` skill at each one and
|
|
follow its red → green loop. Or "none — verify after".
|
|
|
|
**Verify.** The exact commands, e.g. `cd backend && go test ./...`,
|
|
`node --test userscript/test/logic.test.js`.
|
|
|
|
**Out of scope.** What not to touch, especially a sibling ticket's files.
|
|
|
|
</brief-template>
|
|
|
|
## 5. 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.
|
|
|
|
Only once the whole wave is landed does the next wave start — its briefs may
|
|
need what this one changed.
|
|
|
|
## 6. Close the batch
|
|
|
|
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.
|