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.
5.6 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| implement-tickets | Orchestrate a batch of tickets: plan the briefs, then hand each ticket to its own implementer subagent in its own worktree. | 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:
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.