Using Bugbash
Bugbash is not a general development methodology. It is a narrow contract: spend effort proving whether the software misbehaves, under clear boundaries, with evidence you could hand to another engineer.
Philosophy (vs generic “agent frameworks”)
- Outcomes over process: The win is a reproducible finding or a confident “clean for this mission”—not ticking every ritual step.
- Execution first: Prefer running the product; code is for triage after you have signals.
- Honest uncertainty: Separate confirmed bugs from flakes, heuristics, and test gaps—do not blur them.
- No stealth fixes: Do not slip patches in under the guise of “testing.” Fixes are a different user request.
When this applies
Bugbash fits when the user (or parent agent) wants things like: bug bash, QA pass, stress test, break it, edge cases, negative testing, soak, concurrency worries, release confidence.
Usually a mismatch: pure code review without running anything, architecture debates, “why is this slow” deep profiling, or step-by-step debugging where the user already has a stack trace and wants a fix.
What to do
- If the session needs boundaries (environment, timebox, destructive OK), follow Mission brief in
bugbash-core first—keep it short.
- Load
bugbash-core with the Skill tool and run it at the intensity the user asked for (quick, standard, or deep). Default to standard if unspecified.
- For parallel work, split by surface, not by “more generic testers”: e.g.
bugbash-api and bugbash-ui together, then merge into one tracker.
User overrides
CLAUDE.md, AGENTS.md, and direct instructions win. If the user forbids network, shell, or destructive actions, obey and say what could not be exercised.
Platform note
In Claude Code, load skills with the Skill tool rather than reading skill files ad hoc.
1---2name: using-bugbash3description: Use when the user wants to find bugs, stress-test, QA, exploratory-test, or verify behavior by exercising the running system—not for routine implementation, refactors, or fix-focused debugging unless they ask to switch modes after findings exist.4---56# Using Bugbash78Bugbash is **not** a general development methodology. It is a **narrow contract**: spend effort **proving** whether the software misbehaves, under **clear boundaries**, with **evidence** you could hand to another engineer.910## Philosophy (vs generic “agent frameworks”)1112- **Outcomes over process:** The win is a **reproducible finding** or a **confident “clean for this mission”**—not ticking every ritual step.13- **Execution first:** Prefer **running** the product; code is for **triage after** you have signals.14- **Honest uncertainty:** Separate **confirmed** bugs from **flakes**, **heuristics**, and **test gaps**—do not blur them.15- **No stealth fixes:** Do not slip patches in under the guise of “testing.” Fixes are a **different** user request.1617## When this applies1819Bugbash fits when the user (or parent agent) wants things like: bug bash, QA pass, stress test, break it, edge cases, negative testing, soak, concurrency worries, release confidence.2021**Usually a mismatch:** pure code review without running anything, architecture debates, “why is this slow” deep profiling, or step-by-step debugging where the user already has a stack trace and wants a fix.2223## What to do24251. If the session needs boundaries (environment, timebox, destructive OK), follow **Mission brief** in **`bugbash-core`** first—keep it short.262. Load **`bugbash-core`** with the **Skill** tool and run it at the **intensity** the user asked for (`quick`, `standard`, or `deep`). Default to **standard** if unspecified.273. For parallel work, split by **surface**, not by “more generic testers”: e.g. **`bugbash-api`** and **`bugbash-ui`** together, then merge into one tracker.2829## User overrides3031`CLAUDE.md`, `AGENTS.md`, and direct instructions win. If the user forbids network, shell, or destructive actions, obey and say what could not be exercised.3233## Platform note3435In Claude Code, load skills with the **Skill** tool rather than reading skill files ad hoc.
riwaht