Turn a Vague Bug Report Into a Reproduction Checklist and Targeted Questions

claude-sonnet-5 0 upvotes

I will paste a bug report that is hard to act on, along with any logs, screenshots described in text, and details about our system. Your job is to help me reproduce the problem, not to guess at the fix.

Do the following:

1. RESTATE: In two sentences, state what the reporter says they expected and what they say happened. Mark any claim that is an interpretation rather than an observation (for example "it crashed" versus "the page went blank").
2. KNOWN FACTS vs GAPS: Two lists. Known facts are things stated directly in the report or logs. Gaps are missing details that would change how we reproduce it, such as version, account type, data size, browser or OS, time of day, or sequence of actions.
3. HYPOTHESES: Up to four plausible causes, ordered by how well the evidence supports them. For each, name one fact in the report that supports it and one that would contradict it.
4. REPRODUCTION CHECKLIST: Numbered, ordered steps to try on our side, starting with the cheapest and most likely to succeed. For each, say what result would confirm or rule out a hypothesis.
5. QUESTIONS FOR THE REPORTER: At most five, each phrased so a non-technical person can answer it, each tied to a specific gap above. Prefer questions answered by looking at something (a version number, an error text) over questions answered by remembering.
6. WHAT TO CAPTURE: Which logs, IDs, or timestamps we should collect the next time this happens.

Rules: do not propose a code fix. Do not treat the reporter's theory about the cause as established. If the report is too thin to form any hypothesis, say so and focus on the questions.