AI AI Tools Guidebook
Prompt Library

Bug Reproduction Prompts: 12 Templates for Minimal Repro Cases

Go from "it broke" to a minimal, deterministic repro in one prompt. 12 copy-ready templates for shrinking inputs, isolating env, and writing a failing test that lasts.

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

Half of bug-fix time is reproduction. A good repro prompt narrows inputs, isolates the environment, captures the failing state, and outputs a step-by-step that survives the next developer. “It doesn’t work on Tuesday” is not a repro.

These prompts are model-agnostic, but they pay off most in an agentic coding tool that can actually run the steps and read the output. As of June 2026, Claude Code (Sonnet 4.6 / Opus 4.7) runs git bisect, npm test, and shell commands in a feedback loop and writes a failing test before touching the fix; Cursor (running Sonnet 4.6, Opus 4.7, GPT-5.5, or Gemini 3.1 Pro) does the same with its agent mode. The trick is the prompt: tell the model to reproduce first and forbid it from “fixing” before the repro is deterministic.

TL;DR

  • A bug without a deterministic repro is a guess, not a fix. Build the repro first.
  • Shrink inputs by halving (delta debugging / ddmin) until removing one more piece makes it pass.
  • Always convert the repro into a failing test before you write the fix.
  • For “works on my machine” bugs, run the env-diff template before anything else.
  • For prod-only or paid-tier bugs, sanitise data with template 9 before you paste anywhere public.

Who this is for

Engineers triaging support tickets, SREs in incident response, indie devs filing issues on OSS, anyone who has been told “we can’t reproduce”.

When not to use these prompts

Don’t use these for known issues already documented — search first. Don’t use them before reading the actual error / stack — AI can’t reproduce what you haven’t even read.

Prompt anatomy / structure formula

Every repro prompt should carry six elements:

  • Role: who the AI plays (release captain / QA lead / SRE / staff engineer).
  • Context: repo / framework / runtime / branch / diff / failing logs.
  • Goal: one concrete deliverable — checklist, plan, test file, review notes, root cause, ticket list.
  • Constraints: what AI MUST NOT do (don’t auto-fix, don’t silently rewrite, don’t guess versions).
  • Output format: numbered findings, markdown table, JSON schema, unified diff, or runnable code.
  • Examples / signal: 1-2 examples of “good” output, or what bad output looks like.

Best for

  • Turning a vague user report into a deterministic repro
  • Isolating env-specific bugs (works on my machine)
  • Producing a failing test from a bug ticket
  • Repro on a public OSS issue without sharing private data
  • Diff-bisect to find the offending commit

12 copy-ready prompt templates

1. From vague report → minimal repro

You are a senior engineer. User report: "[userReport]". App / version: "[appContext]". Generate a 5-step minimal repro: (1) preconditions, (2) exact actions, (3) expected result, (4) actual result, (5) environment. If a step is ambiguous, list 1-2 clarifying questions instead of guessing.

Variables to swap: [userReport], [appContext]

2. Strip to smallest failing input

Here is a failing input: [input]. Reduce it to the smallest input that still triggers the bug, using delta debugging (ddmin): halve fields / lines / chars, keep the half that still fails, then recurse on smaller chunks. Show each step and whether it still fails. Stop when removing one more character makes it pass. Output the minimal failing input verbatim.

Variables to swap: [input]

3. Reproduction as a failing test

Convert this repro into a single failing test in [framework]. Name: `repro: [bug-title]`. The test should: (a) fail on the current code, (b) be self-contained (no shared fixtures), (c) include a comment with the ticket URL and one-line root-cause hypothesis. Don't write the fix.

Variables to swap: [framework] — Jest / Vitest / pytest / go test; [bug-title]

4. Env diff finder

A bug reproduces in production but not locally. List 12 env differences to check: (1) Node / runtime version, (2) env vars, (3) DB version, (4) timezone, (5) locale, (6) browser version (if FE), (7) memory limit, (8) feature flags, (9) data shape (real vs seed), (10) CDN / cache layer, (11) auth tokens, (12) clock skew. For each: how to compare quickly.

5. Heisenbug isolator

This bug appears intermittently. Distinguish: (a) flake from real bug, (b) race condition vs eventual consistency, (c) ordering issue vs timing issue. For each, propose ONE experiment to confirm. Stop at the first experiment that yields signal — don't run all four.

6. Git bisect plan

Bug exists at HEAD but not at [oldSha]. Write a `git bisect run` script: (1) the test command to run on each commit, (2) exit 0 = good, non-zero = bad, exit 125 = skip (untestable: lockfile-only or merge commits where deps changed), (3) re-install deps inside the script so each checkout is clean, (4) after it lands on the first bad commit, summarise the suspect commit's likely cause. Don't bisect by hand — automate it.

Variables to swap: [oldSha] (a known-good commit). git bisect run returns exit 0 for good, anything non-zero for bad, and treats exit 125 as “skip this commit”.

7. Browser-only repro

Bug shows on mobile Chrome but not desktop. Generate a Playwright script that: (1) launches a mobile emulator (e.g. `devices['Pixel 7']`), (2) reproduces the bug, (3) takes a screenshot at the failing step, (4) writes the console + network log to a file. Keep it ≤ 30 lines and pin the browser channel.

8. Concurrency repro

Suspected race condition in `[functionName]`. Write a stress repro: (1) spin up N concurrent callers, (2) shared state to mutate, (3) assertion that fails if the race happens, (4) print first failing iteration. Don't use `sleep` to force the race — use real concurrent calls.

Variables to swap: [functionName]

9. Private-data-safe repro

For public issues / OSS / Stack Overflow.

Convert this internal repro into a public-safe version: (1) Replace real names / IDs / emails with realistic placeholders, (2) Strip secrets, (3) Keep the failing structure intact, (4) Make it a single runnable file (no internal imports). Output the public file + a one-line note on what was redacted.

10. Repro stability check

Run this repro 10 times in your head: which step is least deterministic? Identify (a) the source of variability, (b) how to pin it (seed, fixed time, fixed input). Output the patched repro plus a one-line confidence note ("now deterministic" / "still 1-in-N flake").

11. Bug repro → ticket template

Turn this repro into a bug ticket: (1) Title ≤ 70 chars, (2) Reproduction steps (numbered), (3) Expected vs actual, (4) Environment, (5) Severity (Sev-1 → 4 with one-line justification), (6) Affected user count if known. No prose intro. No emojis.

12. Cannot-reproduce diagnosis

I cannot reproduce this user-reported bug locally. List 8 reasons it may not repro: stale build, env diff, data diff, race, browser cache, account state, feature flag, time of day. For each: one quick check. Stop at the first check that succeeds — order by cheapest to verify.

Common mistakes

  • Asking AI to fix before you have a deterministic repro — the “fix” is a guess.
  • Skipping the env-diff step on “works on my machine” bugs.
  • Sharing real user data in a public repro.
  • Forgetting to convert the repro into a failing test before fixing.
  • Confusing flake with real bug — fix flake first or you waste hours.
  • Reducing input too aggressively — you remove the part that triggers the bug.
  • No clock / seed pinning on time-dependent repros.

How to push results further

  • A bug without a repro is a feature request. Always invest in the repro first.
  • Reduce inputs by halving (delta debugging). The canonical algorithm is ddmin; see the Debugging Book on reducing failure-inducing inputs for the theory.
  • Always convert the repro to a failing test before you write the fix.
  • For Heisenbugs, start by separating flake from real bug — different fix strategies.
  • For prod-only bugs, env-diff first. Most of the time the environment is the bug.
  • When sharing externally, sanitise data before you paste, not after.
  • Save the repro file in tests/repros/[ticket-id].spec.ts for a future regression check.
  • Hand the failing test to an agent that can run it. Claude Code and Cursor’s agent mode will loop edit → run → re-read until the test goes green, which closes the repro-to-fix gap without you babysitting each step.

FAQ

  • How long should I spend on a repro?: For Sev-1: as much as needed. For Sev-3: cap at 1 hour, then escalate for more info.
  • AI can’t see my prod data — useful?: Yes, for the structure and the test scaffold. The data is yours to fill in.
  • My repro is 1-in-50. Is that “real”?: Often a race condition. Use template 8 to make it deterministic.
  • Should every bug-fix PR include a repro test?: Yes, unless the bug is in code that can’t be unit-tested (e.g., third-party CSS bug).
  • How do I share a repro for a paid-tier bug?: Use template 9 to sanitise. Keep the failing structure, replace data.
  • What if I literally cannot repro it?: Template 12. Most “cannot repro” is env or data drift.
  • Which AI tool should run these?: Anything can draft the repro, but use a tool that can execute it. As of June 2026, Claude Code (Opus 4.7 / Sonnet 4.6) and Cursor’s agent mode run the test in a loop and fix until green. A plain chat window can only hand you the script to run yourself.

Tags: #Prompt #Coding #Debugging #Bug repro

Related Articles