Half my tickets had no repro. Claude drafts the likely steps so I can confirm fast.
The workflow
- Paste the vague ticket
- Ask Claude for likely repro steps and causes
- Confirm against the code
- Update the ticket
Result: A real repro instead of a guessing game.
The prompt
From this vague bug report, propose the most likely reproduction steps and 3 candidate root causes. Report:
[PASTE]A note on what follows. The workflow, the prompt and the result above come from the member. The notes below (why the prompt works, what to watch for, how to adapt it) were written with AI help.
Why this prompt works
Asking for three root causes rather than one is the whole trick. When I asked "what is causing this" I got a confident single answer and I chased it for an afternoon. It was wrong. Three forces it to spread out, and the spread is the useful part: if all three point at the same layer, that layer is probably where the bug lives. If they scatter across frontend, cache and pipeline, I know I do not have enough information yet and I go get more before touching code. The repro steps came second. I added them because a vague ticket is mostly missing observations, not missing theories, and a list of steps tells me what to ask the reporter for. I do not expect the steps to be right. I expect them to be checkable.
What to watch for
- It writes repro steps with total confidence for a system it has never seen. They are hypotheses in the shape of instructions.
- Timezones. Any ticket that mentions "the morning" gets interpreted in some default zone, and half our reports come from a different one.
- It will not tell you the report is unusable. Give it three useless sentences and you still get a neat three-cause list.
- Intermittent bugs get explained as caching almost every time. Sometimes right, often just the most available answer.
How to adapt it
- Paste your stack. Add
The app is Next.js on Vercel with Postgres behind PgBouncer.and the causes stop being generic. - To turn it into a reply to the reporter, add
Also write the three questions I should ask to narrow this down, in plain language. - When you already have logs, add
Rank the causes by which one this log excerpt supports.rather than asking again from scratch.
What good output looks like
Each cause should come with something that would rule it out. "Cache key missing the timezone parameter, check whether two users get different responses to the same cURL" is usable. "Possible caching issue" is not. The repro steps should mention a specific observation to record at each step. If the three causes are really one cause described three ways, I rerun with more context, usually the deploy history.