/bug-bash

name: bug-bash
description: "Programmatic bug bashing, ingest a prescribed test plan (Notion, markdown, pasted spec), drive a real running system (browser via Chrome DevTools / Playwright MCP, backend via API tools when relevant), run every prescribed case with evidence, then do exploratory passes (viewports, edge inputs, multi-actor flows, codebase-driven concerns, additional context like meeting transcripts, emails and links checked in the real inbox with a control case, other languages, failures and races) without ever claiming a bug it didn't itself reproduce. Fills free-text fields with tagged, playful test data that also probes something (unicode, HTML, template syntax, length). Lands results in a local MD file by default, optionally writes back to the source (Notion bug DB, test case Eng QA columns, etc.) in the user's voice. Use whenever the user says 'bug bash', 'QA this feature', 'run the test cases', 'go through this test plan', 'verify these scenarios', 'do a bash on X', when they hand over a Notion test case page, or any time programmatic end-to-end verification of a feature against a checklist is needed. Also use it when a smoke test passed but the user wants more cases tested, or asks 'what else should we test' and then 'test it yourself'. Make sure to use this skill even when the user just says 'test this Notion page' or 'check these scenarios', anything that smells like running someone else's prescribed test plan against a live system."

Bug Bash

A disciplined pass through a prescribed test plan against a real running system. The pass ends when every in-scope scenario has been run, every bug has been *reproduced* (not assumed), evidence is captured, and the results have landed where the user wants them.

This skill exists because of a specific failure mode: when someone hands you a test plan and a transcript of past discussion, the temptation is to just write up "the team already found these bugs" without actually testing. That produces noise, not signal. The whole point of a bash is that *you ran it and saw it*.

---

Why this exists

Most "QA passes" rot in two directions. Either they're a single happy-path click-through that never finds the interesting bugs, or they're an essay summarizing what other people said in meetings. The first misses real defects; the second pollutes the bug tracker with unverified claims that someone else later has to chase down.

A good bash does the prescribed work *and* explores around it *and* keeps a strict line between "I reproduced this" and "someone mentioned this." That line is what makes the output trustworthy.

The second reason this skill exists: the source-of-truth (a Notion test case database, a PRD with acceptance criteria, a markdown checklist) is usually the most important artifact, and it's the part that doesn't get updated. Filling Eng QA columns, adding bugs to the right database, and posting notes in the team's tone is half the work.

---

Step 1: Lock the goal explicitly

**Hard requirement.** Before any other tool call, you (the executing model) MUST call `/goal` yourself, not merely state a goal in prose. A bash walks many cases across many turns and emits a large findings file partway through; without a durable goal, the model tends to stop after the strict pass or after writing the findings file, before the exploratory pass and the write-back. `/goal` is a session-scoped Stop-hook: a fast evaluator checks your condition against the conversation after every turn and makes you continue until it holds. (Grounded in [`docs/research/2026-06-11-claude-code-goal-anti-stall.md`](../../../../docs/research/2026-06-11-claude-code-goal-anti-stall.md).)

Surface the goal to the user first so they can correct scope, then call `/goal` with a condition phrased as something your own output demonstrates (the evaluator cannot run tools or read files):

> Bash `[feature / ticket / PR]`: every prescribed test case has been run against the live system with captured evidence and a recorded status (pass / fail / skip-blocked / skip-external); the eight-lens exploratory pass is complete; every bug recorded is one I reproduced myself (no second-hand claims); results have landed in `[user's chosen sink]`; and the close has been confirmed via the Step 8 AskUserQuestion. Stop after 30 turns if not met.

After setting the goal, create a Todo list (TodoWrite), one item per prescribed test case plus one per exploratory lens, so coverage is tracked while the goal keeps the harness from letting you stop early.

**If `/goal` is unavailable** (untrusted workspace, or `disableAllHooks` / `allowManagedHooksOnly` set): proceed without it, but treat each step's completion as mandatory and do not yield the turn until Step 8.

---

Step 2: Ingest the test plan

Ask the user where the test cases live. The skill must not assume a format. Use `AskUserQuestion` with:

• **Notion URL**: fetch via the Notion MCP, parse the test case database / inline tables
• **Markdown / file path**: read the file, parse the checklist
• **PR / spec description**: paste the URL or text, parse the acceptance criteria
• **Pasting now**: user drops the scenarios directly into chat

After ingestion, restate the test cases back to the user as a numbered list with the *What* and *Should* for each. This is the chance to catch a misread before driving the browser.

If the source contains pre-set columns for results (a Notion "Eng QA" column, a "Status" cell, a checkbox), note them, those are where results will land in Step 7.

---

Step 3: Detect the target environment

Inspect what's being tested and pick the surface area:

| Signal | Target | |---|---| | Test cases describe browser navigation, clicks, form submission, URL changes | `ui` | | Test cases describe API endpoints, request/response shapes, status codes | `backend` | | Both | `both` | | Ambiguous | ask via `AskUserQuestion` |

Verify the right MCP / tool is reachable:

• **UI**: Chrome DevTools MCP or Pla