/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.