# Repro > 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. - Skill: `ucsandman/repro` (Agent Skill) - Install (CLI): `npx skillmds add ucsandman/repro` - Raw SKILL.md: https://api.skillmd.com/api/skills/ucsandman/repro/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: ucsandman (https://skillmd.com/u/ucsandman) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/ucsandman/repro --- # 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: **Severity:** **Surface:** **Environment** - Commit: () - Node: · Platform: - Package/SDK version: - Browser: **Steps to reproduce** 1. 2. ... 3. ... **Actual** **Expected** **Evidence** - **First suspicion (optional)** ``` 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/-.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.