Bug Bash Campaign

Bug-bash campaign

Turn a batch of open bugs into ready-for-review PRs. The work is orchestration: you pick, claim, delegate, judge, and shepherd. You rarely write the fix yourself, and you never merge.

Name the loop at the start (e.g. bugbash42). The name goes in claim comments, scratch directories and the closing campaign memory.

1. Pick

gh issue list --label bug --state open --limit 200 \
  --json number,title,labels,assignees,createdAt

Order: priority:P0 → P1 → P2 → P3, then newest first within a label, and from-sentry ahead of the rest on ties. Take the batch size the user asked for (default 10). Skip issues assigned to someone else, and skip admin-only work (secret rotation, GitHub settings) since it has to go back to Marco anyway.

Prior-art scan before claiming. A matching fix often exists under a branch name with no issue number in it.

• gh pr list --state all --limit 200 --json number,title,body and grep the bodies for the issue number. Grepping titles or branch names alone has missed real fixes.
• gh issue view <n>: a closed event about 1 s after a PR merge is an auto-close, which means the fix already landed.
• find /tmp ~/projects/boardsesh -maxdepth 1 \( -name 'boardsesh-*' -o -name 'wt-*' \): another loop checked out on this issue has effectively taken it. (find, not ls with globs: zsh aborts on a glob that matches nothing.) Adjust ~/projects/boardsesh to wherever your checkouts live.

If a PR already exists but is unmerged, the job is to get that PR ready, not start over.

2. Claim

gh issue edit <n> --add-assignee @me
gh issue comment <n> --body "🤖 Claimed by bug-batch loop \`<loop>\` (batch <N>, session <id>)"

A claim with no PR after about 10 days has lapsed. Reclaim it with a note. Some parallel loops ignore claims entirely, so commit and push early: a pushed commit survives another loop rewriting your worktree.

3. Investigate

One read-only investigator per issue. Scope the prompt as two-phase up front: "investigate now; implement only after coordinator approval". Never write "PLAN ONLY — do not modify files": the permission classifier binds the agent's whole session to that boundary, and neither a later message nor a fresh implementer spawn can lift it cleanly.

Tell the investigator that these are good answers: already fixed on main, duplicate, cannot reproduce, the ticket misdiagnoses the cause. In one 30-issue campaign, 6 were stale, duplicated or overstated. Require it to check the issue's claims against the code.

Keep prod-DB reads out of subagent prompts. A local dev-DB EXPLAIN is fine. Put prod queries in the PR body as a read-only checklist for Marco.

4. Judge the plan

Read every plan yourself.

• Solid → spawn the implementer with the plan embedded.
• Unsure, large, or reframes its own issue → run an adversarial review of the plan first. In moarbugs10000 this found a blocker the author had missed in 4 plans out of 4: an advisory lock that cannot work on a pooled client, a root cause that telemetry contradicted, a cache lock that does not exist, and a rollout step that could not run.

Model by risk: Sonnet for bounded or mechanical work (copy, i18n, tests, small UI). Opus for concurrency, data correctness, security, sync and native code. Pair every implementer with a reviewer.

5. Implement

Worktree per issue, as a sibling of the repo checkout (~/projects/boardsesh/ on the dev box; adjust to wherever your checkouts live), off fresh origin/main:

git fetch origin main
git worktree add -b fix/<issue>-<slug> ~/projects/boardsesh/wt-<issue> origin/main

Never under /tmp or .claude/worktrees/ (the mobile bundle check needs a sibling worktree).

Paste this block into every implementer prompt, replacing <scratchpad> with the absolute path of your session's scratchpad directory (Claude Code names it in the system prompt; subagents share it; with none, use ${TMPDIR:-/tmp}/<loop>) and <issue>/<loop> with real values:

• Prove each guard fires: revert the fix, watch the test go red, restore, and paste the real red output. A new lint rule or checker needs a deliberately broken fixture.
• Report any unverified step as unverified. "CI is authoritative for X" is fine; claiming green you did not see is not.
• Commit before mutating code to test a guard. git checkout -- <file> also throws away uncommitted real work.
• Scratch files go in <scratchpad>/<issue>-<loop>/ with unique names. The shell has noclobber on, so write files with the Write tool or >|, never bare >. Read the file back right before --body-file, and re-read the published PR body with gh pr view.
• Run tests in the FOREGROUND with generous timeouts. Do not start background tasks or monitors and wait on them.
• Local checks are scoped only: vp check on touched files, vp run typecheck:backend|shared|db|mobile, one targeted test file. No full backend suite and no typecheck:web (it runs a Next build); several of those at once exhaust the box's memory. Push a draft and let CI run the full sweep.
• Read upstream behaviour out of node_modules, not memory. Resolve fingerprint impact with vp exec expo-updates runtimeversion:resolve or the PR's OTA check; never assert it.

Read the diff and the red output yourself before believing a report. If an agent stalls twice, stop resuming it: check git status, validate its edits, and land them from the main session.