AI AI Tools Guidebook
Prompt Library

Bug Reproduction Prompts: 12 Templates for Minimal Repro Cases

Get from "it broke" to a minimal reproduction in one prompt. 12 templates for narrowing inputs, isolating env, capturing logs, and writing a repro that lasts.

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

Half of bug-fix time is reproduction. A good repro prompt narrows inputs, isolates env, 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.

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. Bisect by halving fields / lines / chars. 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 / pytest / go test

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}. Plan a `git bisect`: (1) what command to use as the test, (2) how to mark good / bad without false positives (e.g., re-install deps), (3) commits to skip (merge commits, lockfile-only changes), (4) the suspect commit's likely cause.

Variables to swap: oldSha

7. Browser-only repro

Bug shows in Chrome 120 mobile but not desktop. Generate a Playwright script that: (1) launches mobile emulator, (2) reproduces the bug, (3) takes screenshot at the failing step, (4) outputs the console + network log to a file. Keep it ≤ 30 lines.

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 — fastest convergence on the minimal case.
  • 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 env is the bug.
  • When sharing externally, sanitise data BEFORE you paste, not after.
  • Save the repro file in tests/repros/<ticket-id>.spec.ts — future regression check.

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.

Tags: #Prompt #Coding #Debugging #Bug repro

Related Articles