bug-sweep
Skill0 starsChanged 46 days agoMITView on GitHub
Systematic audit→fix→rescan over a code surface to find MANY bugs, not one reproduced bug. Walks the same surface through seven lenses (logic, boundaries, error handling, state/lifecycle, data integrity, concurrency-adjacent, API misuse), one lens per pass, dedupes the candidates, verifies each is real before touching anything, fixes the survivors no-slop under a green ratchet with a regression test each, then re-sweeps until consecutive sweeps come up dry. Use when "sweep this for bugs", "find all the bugs in this module", "deep bug pass", "comb through this", "audit this surface for defects", or when bug-zero routes its systematic audit→fix→rescan class here.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- PeyHunter/skillstheir own version, first seen Oct 6, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- PeyHunter/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository51 other files it gives its agents.
- advisor-councilSkill
- advisor-persona-buildSkill
- agent-exploit-pathsSkill
- agentic-loopsSkill
- ai-receptionist-tenant-onboardingSkill
- audit-lensSkill
- beadsmithSkill
- bug-zeroSkill
- build-in-public-scope-guardSkill
- consulting-sales-playbookSkill
- deepenSkill
- deposit-first-shippingSkill
- design-intelSkill
- dueling-idea-forgeSkill
- forgeSkill
- hotspot-scoutSkill
- idea-forgeSkill
- incident-zeroSkill
- kickstartSkill
- local-llm-opsSkill
- memguardSkill
- memory-forgeSkill
- migrate-proofSkill
- no-slop-bug-hunterSkill
- optimize-proofSkill
- perf-maxSkill
- polish-passSkill
- problem-breakthroughSkill
- project-autopilotSkill
- qwen-bug-zeroSkill
- qwen-forgeSkill
- qwen-kickstartSkill
- qwen-perf-maxSkill
- qwen-project-autopilotSkill
- qwen-ship-itSkill
- qwen-ux-maximizerSkill
- readme-realSkill
- reality-checkSkill
- recallSkill
- security-sweepSkill
- session-mineSkill
- ship-itSkill
- simplify-proofSkill
- skillifySkill
- stream-demo-prepSkill
- swarm-runSkill
- test-maxSkill
- trace-itSkill
- unslopSkill
- ux-maximizerSkill
- ux-scanSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Bound the surface before pass 1: Use an explicit file list, plus one line on what each file is *supposed* to do (a bug is a divergence from …
- Distinctive: line 64
Concurrency-adjacent: check-then-act, non-atomic read-modify-write, lazy-init races, mutating while iterating.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Bug Sweep
The breadth finder. no-slop-bug-hunter kills one reproduced bug; this combs a whole surface for the population. The trick is that one read of code only finds the bugs you were primed to see. So it reads the same lines seven times, each pass primed by a different lens, collects everything, then verifies before it fixes and re-sweeps after it does. It stops when sweeps come up dry, not when a pass counter runs out.
Core Insight: Bug-finding yield is set by priming, not effort. Ask a model to "find the bugs" and it finds the three most obvious, declares the file clean, and is wrong: the boundary bugs and lifecycle bugs were invisible because nothing pointed the read at them. Seven narrow passes over the same surface out-find one broad pass every time. And because every finder over-reports, the second half of the trick is the firewall between finding and fixing: a candidate is not a bug until it survives an adversarial re-read at its own file:line, and a fix is not banked until a test that fails on the buggy code says it's real.
Preconditions / guards
- Bound the surface before pass 1. Use an explicit file list, plus one line on what each file is supposed to do (a bug is a divergence from intent; no intent, no verdict). "The whole repo" unbounded dilutes every lens; sweep a subsystem at a time.
- Standalone mode: green baseline + checkpoint. The ratchet needs a known-good start. Suite already red → escalate for a green baseline before any fix. Callee mode (called by bug-zero): read-only, touch nothing. The orchestrator owns verify/fix/prove.
- Never weaken tests to reach green. Deleting/skipping assertions hides bugs.
- Top-model work, no qwen variant. Lens reading is adversarial close-reading, which is exactly what small models hallucinate at. Phantom findings poison the whole downstream loop.
The seven lenses (one per pass)
Each pass walks the ENTIRE surface looking for ONE class only. Full telltales, greps, and the verify question per lens are in references/LENSES.md:
- Logic errors: inverted/wrong conditions, wrong variable, copy-paste branch
not edited, unit mismatches, operator slips (
<vs<=,andvsor). - Boundary / edge cases: empty, zero, one, negative, max, last iteration, off-by-one in slices/pagination, float equality, unicode, midnight/DST.
- Error handling: swallowed exceptions, broad catches, error paths returning a shape the caller can't take, missing cleanup on the failure branch, lying exit codes.
- State & lifecycle: stale cache after mutation, init-order dependence, mutable default args, request state in singletons, missing reset between iterations, double registration, teardown order.
- Data integrity: lossy conversions, partial writes with no atomic rename, multi-step mutation with no transaction, round-trip asymmetry, null vs missing-key conflation, naive datetimes crossing a boundary.
- Concurrency-adjacent: check-then-act, non-atomic read-modify-write, lazy-init races, mutating while iterating. (Shallow shapes only. Anything that smells like a real deadlock/race hands off to deadlock-finder-and-fixer.)
- API misuse: same-typed args swapped, failure-signaling return values ignored, semantics that changed in the version actually pinned, shell-quoting and regex pitfalls, locale/timezone-sensitive calls.
The Pipeline (staged: issue each phase only when the prior finishes)
Phase 0 BOUND Fix the surface: explicit file list + intent per file (guard #1).
Standalone: establish + checkpoint a green baseline.
Phase 1 PASSES Seven passes, one lens each, over the SAME surface. Collect
candidates. DO NOT fix anything mid-pass. Log per-pass yield
("pass 4 state/lifecycle: 3 candidates") so the tail is visible.
Phase 2 DEDUPE Merge candidates that share a root cause (two lenses hitting one
bug = ONE finding carrying both tags). Emit the findings list in
the record format below.
── CALLEE MODE ENDS HERE: hand the list to bug-zero. ──
Phase 3 VERIFY Adversarially re-read EVERY candidate at its cited file:line. Is
it real, reachable, a divergence from intent? Or enforced one
layer up? Default to "not a bug" if uncertain; a phantom fixed is
worse than a bug skipped. Doubtful → multi-model-triangulation.
Phase 4 FIX Survivors only, batches of ≤5, under the green ratchet, with
no-slop-bug-hunter's per-fix contract verbatim: root cause named
in ONE sentence, exact scope named, fix THE bug not the category.
Each fix ships a regression test that FAILS on the buggy code.
A fix that reds any test → revert that batch. In a beads repo:
one br issue per confirmed bug, closed by the fixing commit.
Phase 5 PROVE Run the repro; watch each bug be gone. "Tests pass" isn't proof.
Phase 6 RESCAN Full re-sweep, ALL seven lenses. Fixes shift the surface, and a
lens that was dry last sweep can produce now. DRY = a full sweep
finding nothing materially new. Stop at K=2 consecutive dry
sweeps (saturation), never at a fixed pass count.The findings record (the contract)
One block per deduped finding. This exact shape is what bug-zero's VERIFY consumes:
- id: cache-invalidate-misses-mirror # stable slug = cross-finder dedupe key
lens: [state-lifecycle, data-integrity] # every lens that hit it
class: stale cache after mutation
where: src/cache.py:142
why: invalidate() clears the local dict but not the redis mirror, so the next
read within TTL serves the deleted entry
repro: delete a key, GET it twice inside the TTL window
severity: wrong-result # data-loss > crash > wrong-result > degraded > cosmetic
status: candidate # candidate | confirmed | phantom | fixedid + where make merging with another finder's output mechanical; lens tags let
the orchestrator see which reading found what; why is one sentence or it isn't done.
Contract (what orchestrators rely on)
- bug-zero routes "Systematic audit→fix→rescan over a surface" here in its Phase 1 SWEEP. Callee mode: run Phases 0–2 read-only and return the deduped, lens-tagged candidate list into bug-zero's Phase 2 VERIFY. From there bug-zero owns sequencing, the verify loop, the ratchet, and proof. Do not fix, do not verify, do not dedupe against other finders (bug-zero merges the union).
- Standalone owns the full loop end-to-end, Phases 0–6.
- Division of labor with no-slop-bug-hunter: one reproduced symptom → that skill; "how many bugs are in here" → this one. This skill's Phase 4 is that skill's contract applied per survivor.
Skills it composes with
no-slop-bug-hunter: the per-fix discipline Phase 4 inherits. bug-zero: the orchestrator that calls it and merges it with the other finders. multi-model-triangulation: doubtful or high-stakes candidates before any fix. deadlock-finder-and-fixer: handoff target when lens 6 smells a real race. verify / run: Phase 5 proof. beads-br / beads-bv: confirmed-bug tracking and triage when the surface lives in a beads repo.
THE EXACT PROMPT
/bug-sweep
Surface: <files / module / subsystem — explicit, bounded>
Mode: standalone | findings-only (bug-zero callee)
Lenses: all (default) | <subset, e.g. error-handling,state-lifecycle>Anti-Patterns
- One broad "find the bugs" pass instead of lens-per-pass. You find only what you were primed for and declare clean too early.
- Fixing mid-pass. Finding and fixing in the same breath narrows the read; collect first, fix in Phase 4.
- Fixing a candidate before it survives Phase 3. This is the cardinal sin; every finder over-reports, including this one.
- Grep-and-patch off one finding. Sibling instances of the pattern ARE in scope for a sweep, but each is its own finding, verified independently at its own line.
- A fixed pass count or stopping at literal zero. DRY means K=2 consecutive full sweeps with nothing materially new.
- Dropping a lens because its last pass was dry. Fixes shift the surface; the rescan runs all seven, every time.
- Drive-by refactors, symptom-swallowing try/except, feature flags as fixes. The no-slop contract applies to every fix in the batch.
- Banking a fix whose regression test doesn't fail on the buggy code.
- Callee mode touching the working tree. Findings go up; hands stay off.
- Running the passes on a small local model. Phantom candidates flood the verify loop and burn the saved tokens tenfold.
References
- LENSES.md: the seven lenses expanded. What each pass reads for, telltale shapes and greps, and the verify question that decides real vs phantom.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

