From Vague Bug Report To Reproducible Ticket

Support forwards "checkout is broken on mobile". An engineer needs steps, an environment, an expected result and an actual result. Bridging that gap by hand is twenty minutes and a Slack thread.

`
Turn the report below into a bug ticket with these fields:

Title - one line, states the symptom not the guess at the cause
Environment - device, OS, browser, app version, account type
Steps to reproduce - numbered, each step one action
Expected result
Actual result
Severity - with a one-line justification

Then a section headed MISSING INFORMATION listing every field above
you could not fill from the report, written as the exact question to
ask the reporter.

Do not invent any detail that is not in the report. An empty field is
correct; a plausible guess is not.
`

The MISSING INFORMATION section is the entire feature. A ticket that quietly guesses "iOS 17, Safari" is worse than no ticket - someone spends an hour failing to reproduce on the wrong platform. A ticket that says "Ask: which browser, and does it also happen in a private window?" is immediately actionable by the person who is already talking to the customer.

"Symptom not the guess at the cause" in the title stops the whole team anchoring on a wrong theory for three days because the first person to write it down said "caching issue".

Severity with a justification is what makes the field survive. Severity alone is a number nobody trusts. "P1 - payment completes but the confirmation screen never renders, so users retry and double-pay" is an argument, and it either holds or it does not.

I have this saved as a snippet and paste it above the raw report. Twenty minutes down to about ninety seconds, and the tickets are better than the ones I was writing.