repro

name

repro

description

Turn a bug symptom into a structured, reproducible bug report — summary, environment, exact repro steps, actual vs expected, and evidence (logs, error text, failing route/test) — and then optionally scaffold a failing regression test that pins it. Use this the moment a bug, defect, crash, 500, wrong count, broken page, or "this used to work" is reported and you're about to start fixing it, even if the user just pastes an error or says "X is broken". A structured report makes a far better fix prompt than a raw symptom and becomes the regression test that stops the bug coming back. Trigger on: repro, reproduce, bug report, file a bug, "X is broken", "getting a 500", "why is this failing", regression test for a bug, write up this bug.

repro — symptom in, structured bug report out

A raw symptom ("the decisions page is blank") is a weak fix prompt: it forces whoever fixes it to re-derive the environment, the steps, and the expected behavior from scratch, and it leaves nothing behind to prove the bug stays fixed. A structured bug report front-loads that work once, turns into a sharp fix prompt, and — its highest-value output — becomes a failing regression test that pins the defect forever.

This skill produces that report, then offers to scaffold the test. It does not fix the bug — capturing it cleanly is the whole job; hand the report to the fix (or to /systematic-debugging) afterward.

The report format — use this exact structure

Emit the report as one contiguous, pasteable block (no leading > quote markers, no mid-sentence line breaks — Wes pastes these into prompts and issues):

## BUG: <one-line summary — the observable failure, not the guessed cause>

**Severity:** <blocker | major | minor — blocker = data loss/security/prod down>
**Surface:** <page + click path, or route, or CLI command, or SDK method>

**Environment**
- Commit: <short sha> (<branch>)
- Node: <version>  ·  Platform: <os>
- Package/SDK version: <if relevant>
- Browser: <only if a UI bug>

**Steps to reproduce**
1. <exact, replayable step — real values, not "do the thing">
2. ...
3. ...

**Actual**
<what happens — verbatim error, status code, stack line, screenshot ref>

**Expected**
<what should happen, and why you believe that — cite the spec/route/test>

**Evidence**
- <log snippet, failing assertion, network response, file:line>

**First suspicion (optional)**
<one sentence — a lead, explicitly marked as unverified so it doesn't anchor>

Two rules that keep the report honest:

• Summary = the symptom, never the guessed cause. "Decisions page renders blank" is reproducible and verifiable; "DecisionsLedgerInner crashes on null agent" is a theory that may be wrong and will mislead the fixer. Keep the theory in First suspicion, clearly fenced off.
• Steps must be replayable by someone with none of your context. If a step reads "with the right filter set," it's not a step — name the filter and the value.

Fill the fields cheaply — don't interrogate the user

Auto-populate the boring fields before asking the user anything. From C:\Projects\DashClaw:

• Commit + branch: git rev-parse --short HEAD and git branch --show-current
• Node + platform: node -v; platform is win32 (this repo's dev box)
• Version: read package.json version when the bug touches the platform or an SDK surface
• Evidence for API bugs: reproduce the call and capture the real response — curl/the SDK against the local dev server (npm run dev, port 3000) beats quoting from memory
• Evidence for UI bugs: the frontend-verify skill already captures console errors + failed requests to disk — pull the failing route's entry rather than clicking by hand

Only ask the user for what you genuinely can't observe: the intended behavior when it isn't written down anywhere, or repro steps for a flow you can't reach. State your assumptions and proceed rather than stalling on a round-trip.

Then offer the regression test

After the report, offer: "Want me to scaffold a failing regression test that reproduces this?" A bug without a test is a bug that comes back. If yes, follow DashClaw's vitest conventions (they're non-obvious — see the notes below), write the test so it fails on today's code for the bug's reason, and say so explicitly. A regression test that passes before the fix is proving nothing.

Name it after the defect, not the function: __tests__/unit/<area>-<symptom>.regression.test.js.

DashClaw vitest conventions that will trip you up if you skip them:

• Tests live in __tests__/ (unit/integration/smoke). Run the full suite with npx vitest run — targeted runs miss cross-file regressions.
• No jest-dom. Use vitest's own matchers + @testing-library queries.
• @/ resolves to app/. Mock next/navigation for anything that reads route params. A .jsx import can resolve to a .tsx file.
• Postgres numerics come back as strings from the Neon driver — assert on the coerced value, not the raw.
• For guard/policy behavior, prefer adding a vector to the risk-calibration golden suite over a bespoke test — that's where scoring regressions are pinned.

If the test can't be written cheaply (needs live external state, a real browser flow, a paid provider call), say so plainly and describe the manual repro instead of forcing a brittle test — a flaky test is worse than an honest note.

What this skill does not do

• It does not fix the bug. Report, optionally pin with a test, then hand off.
• It does not open a tracker or PR (this repo commits to main; the report is the artifact — paste it into the fix prompt, the maintainer log, or CHANGELOG).
• It does not guess the root cause with confidence. Leads go in First suspicion, fenced and unverified.