sulthan
3ac865cd08
Removes the graphify integration. It was measured against this repo rather than assumed. ## Why `graphify query` returns a keyword-seeded BFS neighbourhood, not a location. Asked where CORS origin reflection is implemented, it returned 73 nodes — mostly `api_test.go` helpers, plus a `Reflection and Type Assertions` section from `.agents/skills/golang-performance/references/cpu.md` matched on the word "reflection" — and never named `httpmw/middleware.go:135` or `main.go:121`. `grep` returned both in 39ms. Same shape asking how the poller skips kagane: 145 nodes, top hits `poller_test.go` helpers and two nodes named `T`. `graphify explain "BrowserFetcher"` is sound (`browser.go L52`, 9 `EXTRACTED` edges), but that is what `lsp references` already answers, against live files instead of a snapshot. Staleness was never the problem — `graph.json` rebuilt 5s after `f568fb5`, so the git hooks worked. Retrieval quality was. ## What it cost - Two `PreToolUse` hooks injecting a "MANDATORY: run graphify query first" paragraph into context on **every** grep/find and every source-file read. - 685k input tokens across 5 build runs (`cost.json`). - 3.4MB of `graph.json` + `graph.html` tracked, across 11 commits of map-refresh churn. `AGENTS.md` is the stronger orientation artifact for a repo this size: it carries the CDP constraints, the UTC-clock finding, the per-site adapter list, and the security invariants — none of which an AST graph derives. Graphify earns its keep on repos too large to grep coherently and without curated docs; not this one. ## Changes - Delete the committed map (`graphify-out/`, -58k lines). - Drop the `## graphify` rules block from `AGENTS.md` (`CLAUDE.md` is a symlink, so both). - Drop the five `graphify-out/*` entries from `.gitignore`. - Empty the two `PreToolUse` hooks in `.claude/settings.json`. - Remove the stale `graphify query` instruction from `.claude/skills/implement-tickets/SKILL.md` — it pointed dispatched ticket-implementer agents at a binary that no longer exists. Uninstalled outside the tree (not in this diff): the `graphifyy` CLI, `~/.claude/skills/graphify/`, the global `~/.claude/CLAUDE.md` block, the `Bash(graphify query *)` permission in the git-ignored `.claude/settings.local.json`, and the `post-commit` / `post-checkout` git hooks. ## Verification `grep -ri graphify` over the worktree is clean; remaining hits are inside `.git/` (commit messages, two stale branch configs). No code touched — backend and userscript are untouched, so `go test ./...` is unaffected. Reviewed-on: #111 Co-authored-by: Sulthan Zaki <sultankiki05@gmail.com> Co-committed-by: Sulthan Zaki <sultankiki05@gmail.com>
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.