There is a specific phrase that used to ruin my afternoons: "Cannot reproduce — closing." I would forward a customer bug report to engineering, a developer would spend twenty minutes failing to make the bug happen, and the ticket would ricochet back to me with that note attached. The customer was still broken. The engineer was annoyed. And I was the human bottleneck in the middle, re-asking questions I should have asked in the first place.
I counted once. In a single sprint, eight of my fourteen escalated tickets came back unreproduced. That is not a bug problem. That is a translation problem. And the cost was not only my time — every bounce meant the customer waited another day or two while the ticket ping-ponged, which meant a second frustrated message, which meant more of my time again. Bad tickets do not just fail; they generate more bad tickets.
Customers and engineers speak different languages
A customer writes "it's broken again, the thing won't load and it's driving me crazy." An engineer needs steps to reproduce, expected versus actual behaviour, and the exact environment. The chasm between those two sentences is precisely where tickets go to die. My job was to bridge it, and I was doing it badly because I was doing it in a hurry between live chats. Translation is real cognitive work, and I was trying to do it in the ninety seconds between two other fires.
Worse, I had a tell: when a report had gaps, I would quietly fill them with plausible-sounding guesses to make the ticket look complete and competent. "Probably Chrome on Windows." "Likely happens every time." That is the single fastest way to make a ticket unreproducible. Engineering follows my invented step three, it does not match reality, and the whole thing collapses — except now it collapses with my confident fiction attached, so the engineer trusts the next ticket I send even less.
Running every report through Opus before it ships
Now every bug report goes through the Turn a Vague Bug Report into a Reproducible Ticket prompt on Claude Opus 4.8 before an engineer ever sees it. I picked Opus deliberately — this task is careful reasoning under uncertainty, separating what a customer literally said from what I am tempted to assume, and Opus is patient about exactly that. The prompt's XML structure tells it to tag every inferred step with [INFERRED] and every missing environment field with [UNKNOWN], so my guesses are visible as guesses instead of disguised as facts.
The output I did not know I needed was the prioritized list of clarifying questions. Instead of dumping an incomplete ticket on engineering, I now send the customer two or three sharp questions first, get the answers, and the ticket arrives reproducible on the first try. The prompt is strict about ordering them, too — it leads with the one question that would unblock reproduction fastest, so I am not asking the customer for their browser version when the real unknown is which button they actually clicked.
There is a discipline buried in that ordering that improved how I think, not just how I write. Before, I would fire off a scattershot of five questions and annoy the customer. Now I ask the two that matter, the customer feels respected instead of interrogated, and I get usable answers faster. The structure quietly taught me to triage my own curiosity.
- [INFERRED] tags tell engineering exactly which steps were my guesses versus the customer's confirmed facts
- Clarifying questions go to the customer first, so tickets land already reproducible
- 'Cannot reproduce' bounce-backs dropped by roughly half in the first month
- One senior engineer literally said my tickets were the easiest in the queue to pick up
Honest gaps beat confident fiction
The rule that changed everything was 'never invent reproduction steps.' It sounds obvious, but my completeness instinct fought it hard. A ticket with [UNKNOWN: app version] on it looks less impressive than one with a confidently fabricated version number. It is also infinitely more useful, because engineering knows precisely where the uncertainty lives instead of chasing a number I made up.
I keep this in a tight loop with my Write an Escalation Note Engineering Will Actually Action prompt — Opus structures the reproducible ticket, and when the bug is genuinely urgent the escalation note carries it upstairs with honest impact attached.
Grab the Turn a Vague Bug Report into a Reproducible Ticket prompt on Prompt Dock and run it on the next "it's just broken" report that lands in your queue. Your engineers will not send you flowers, but they will stop closing your tickets unread, and in this job that is basically the same thing.