The Bug Report Said 'It Doesn't Work.' That Was The Whole Report.

A support ticket lands in the engineering queue. The subject line is "Export broken." The body reads: "It doesn't work. Please fix ASAP." No browser, no account, no steps, no screenshot. An engineer picks it up, can't reproduce it on their own account in thirty seconds, and either closes it as "cannot reproduce" or spends the next hour guessing at what "it" and "doesn't work" might mean.

Multiply that by every vague bug report a team gets in a week, and the real cost isn't any single ticket, it's the compounding tax of engineers doing detective work that a slightly better report would have made unnecessary. The information usually does exist somewhere, in the reporter's head, in a support conversation, in a half-remembered detail, it's just never assembled into something a developer can act on directly.

That's the exact gap this prompt closes: Turn a Bug Report Into Reproducible Test Steps. Paste in whatever you've got, however incomplete, and it turns it into steps a developer can actually follow, plus a specific list of what's still missing if the original report genuinely isn't enough.

Why vague bug reports are so expensive

The hidden cost of a bad bug report isn't the time to read it, it's the round trips. An engineer reads "it doesn't work," can't reproduce it, and has to go back to the reporter (a customer, a support agent, a teammate) and ask what they actually meant. That reply takes hours or days to come back, often with only slightly more detail than the original, requiring another round trip. A bug that could have been fixed in twenty minutes with a clear report can take a week of back-and-forth with a vague one, not because the bug was hard, but because no one could agree on what it even was.

This gets worse under time pressure, which is exactly when it matters most. A vague report about a broken checkout flow during a sale, or a broken export the night before a client deadline, doesn't get less vague because it's urgent. If anything, urgency makes people write faster and less precisely, exactly when precision would save the most time.

How the prompt actually helps

The prompt doesn't try to guess its way to a fix. It restates what's actually being claimed as broken in one clear sentence, which alone catches a surprising number of cases where "it doesn't work" turns out to mean three different possible things depending on how you read it. Then it identifies the preconditions a developer would need to reproduce the issue, account type, data state, browser, whatever the original report left out, and flags those as gaps rather than filling them in with assumptions.

Where there's enough information, it produces numbered reproduction steps precise enough for someone unfamiliar with the original report to follow exactly, and states expected versus actual behavior as two distinct sentences instead of one blurred complaint. Where there genuinely isn't enough information, it doesn't paper over the gap with a plausible-sounding guess, it produces the specific follow-up questions to send back to the reporter, so that one clarifying message asks for everything needed at once instead of trickling in one missing detail per round trip.

A worked example

Take that "Export broken. Please fix ASAP" ticket. Run it through the prompt with whatever surrounding context exists, maybe a support agent's note that the customer mentioned "the CSV thing" and is on a paid plan.

The restated claim becomes: "Customer reports the CSV export feature is not producing a usable file." The preconditions section immediately flags what's missing: account type is known (paid plan) but browser, export size, and whether this affects all exports or one specific report type are not stated anywhere in the original ticket. Since there isn't enough to write confident reproduction steps yet, the output skips straight to the follow-up questions: which specific export were you trying to run, what happened when you tried (an error message, a blank file, nothing downloading at all), and which browser and device. One message covering all three, instead of three separate rounds of "can you clarify."

Where the value actually lands

The time saved isn't in writing the reproduction steps faster, it's in collapsing what would have been several slow round trips into one clarifying ask, or skipping the round trip entirely when enough detail already exists to reproduce directly. That compounds fast across a team fielding dozens of reports a week, especially when reports are coming through a support layer that didn't originally capture technical detail because that's not what a frustrated customer thinks to include.

It also creates a better paper trail. A restated one-sentence claim plus explicit expected-versus-actual behavior is something a developer can paste directly into a ticket, a commit message, or a QA note, which holds up much better over time than a customer's original half-sentence complaint once the original context has faded from memory.

How to use it

1. Paste in the bug report exactly as received, however sparse, along with any surrounding context you have (support notes, a Slack thread, anything).
2. If the output produces clean reproduction steps, hand them straight to the engineer or QA picking up the ticket.
3. If it produces follow-up questions instead, send those as one consolidated message back to the reporter rather than trickling out one question at a time.

Grab the full prompt here: Turn a Bug Report Into Reproducible Test Steps.