What this prompt does
This prompt produces a minimal, self-contained bug reproduction in a single runnable file — the kind that turns a vague report into something maintainers can act on. It casts the assistant as a senior [language] engineer who writes flawless minimal reproductions and takes four context variables: [language], [max_lines], [environment], and [bug_description]. The deliverables are one self-contained file under the line cap with no external services, only the code needed to trigger the bug, inline comments pointing at the suspected cause, run instructions for the environment, expected versus observed output side by side, and a one-line hypothesis for why it happens.
The structure works because the hardest part of a good repro is subtraction, not addition. By enforcing [max_lines] and "no external services," the prompt forces the model to strip everything unrelated until only the triggering code remains. The expected-versus-observed pairing is what makes the report instantly legible to a maintainer — they see the gap immediately. The one-line hypothesis gives a starting point for the fix without over-committing to a diagnosis.
When to use it
- Filing a bug report on GitHub, a gist, or Stack Overflow that won't bounce back
- When a report keeps getting "can't reproduce" and you need something airtight
- When you want to isolate a bug from a large codebase down to its essence
- When answering someone else's vague issue and need a clean repro to reason about
- When you suspect a library bug and need a case the maintainers can run instantly
- When debugging is stalled because the failure is tangled up in unrelated code
Example output
You get a single file under [max_lines] lines that runs with no external services, containing only the code needed to trigger the bug. Inline comments point at the suspected cause so a reader knows where to look first. Below or alongside it, run instructions for [environment], the expected output and the observed output shown side by side, and a one-line hypothesis. Nothing extraneous — the whole artifact is built to be pasted into an issue and run as-is. The side-by-side output block is what does the heavy lifting, because it communicates the bug faster than any paragraph of description and removes the usual round of clarifying questions.
Pro tips
- Set
[max_lines]aggressively low; a tighter cap forces a cleaner, more legible repro - Pin
[environment]precisely ("Python 3.12, standard library only") so the maintainer's run matches yours - Lead your issue with the expected-versus-observed block — it's the fastest way to communicate the bug
- If the first repro still pulls in a dependency, push back and demand a standard-library-only version
- Give
[bug_description]enough detail to reproduce; a thin description yields a thin repro - Treat the one-line hypothesis as a lead to verify, not a confirmed root cause
