The task
Support inbox: “It’s broken.” Five-word complaint, zero context, zero reproduction steps. You need a bug report engineering can actually act on — specific title, numbered steps, expected versus actual behaviour, severity, and environment. The bonus is the clarifying questions you should ask the user before filing, so engineering does not bounce the ticket.
When AI helps — and when it does not
AI is excellent at structuring vague messages into the standard bug report shape and at writing clarifying questions that pin down ambiguity. It is poor at guessing the root cause — if AI confidently writes “this is a state-management issue,” delete that line. The ticket describes the bug; the engineer diagnoses it.
What to feed the AI
- The user’s verbatim message
- Device, OS, app version (if extractable from headers, logs, or the user’s email)
- Whether you can reproduce, partially reproduce, or cannot
- Repro steps if any
- Account state if relevant (free / paid, locale, recently changed plan)
- Your team’s severity scale (S0 / S1 / S2 / S3)
Copy-ready prompt
Convert this user complaint into a bug report.
User message (verbatim):
"""
<paste>
"""
Device / OS / version: <paste or "unknown">
Repro status: <can repro / partial / cannot>
Repro steps if any: <paste>
Account state: <free / paid / locale / recent changes>
Severity scale: <S0-S3 definition>
Return:
1. Title — specific, scannable, includes feature area
2. Steps to reproduce, numbered
3. Expected behaviour
4. Actual behaviour
5. Severity (S0-S3) — with reasoning tied to user impact
6. Environment — device, OS, version, region
7. Clarifying questions to ask the user before filing — 3 max, prioritised
8. A "do not assume" callout — root-cause speculation I should remove from the ticket
If user info is missing, do not invent it. Use [UNKNOWN: ask user].For mobile-specific bugs: “Add iOS / Android divergence check — same repro on the other OS?”
Recommended output structure
A ticket with title, steps, expected / actual, severity, environment, and a clarifying-questions list. The “do not assume” callout removes wild guesses before they propagate. Use your team’s template if it differs.
How to check the output is usable
- Title is searchable — includes feature area, not “app is broken”
- Steps reproduce the bug in your own test
- Expected vs actual are both stated — engineering cannot work without both
- Severity has reasoning, not just a tag
- Clarifying questions are answerable in one line by the user
- No root-cause speculation in the ticket body
Common mistakes
- Filing vague reports — engineering bounces the ticket; user grows frustrated
- No expected vs actual — most common “needs more info” reason
- No severity assigned — sits in triage purgatory
- Letting AI guess root cause — feels helpful, derails engineering
- Skipping clarifying questions — better to ask before filing than after
- Not capturing environment — bugs that exist only on one OS get assigned to the wrong team
Practical depth notes
For How to Use AI to Write a Bug Report: Vague Complaints into Reproducible Tickets, the difference between a usable AI result and a generic one is the input packet. Give the model the audience, the current draft or raw material, the desired format, the decision you need to make, and two examples of what good and bad output look like. Ask it to preserve facts first, then improve structure or wording second.
After the first response, do a separate review pass. Look for missing constraints, invented details, weak calls to action, and language that sounds plausible but does not match the real situation. The best final output should be easy to use immediately: clear owner, clear next step, and no hidden assumption that someone else has to untangle. A stronger version of this workflow also defines the handoff. Decide who will use the output, what they should do next, and what information would make them reject it. If the deliverable is copy, test whether it has a single clear action. If it is analysis, test whether it separates observation from recommendation. If it is planning, test whether dates, owners, and tradeoffs are explicit enough for someone else to execute. One final check: compare the finished result against the original goal in a single sentence. If that sentence is hard to write, the output is probably polished but unfocused. Tighten the goal, remove decorative language, and rerun only the weak section instead of regenerating the entire piece.
FAQ
- What if the user is hostile? Reply gently before clarifying. Tone matters for whether they answer.
- Severity disagreements with engineering? Defend your severity with user-impact reasoning, not feature importance.
- Should AI categorise the bug area? Yes if your taxonomy is consistent. Otherwise have a human triage.
Related
- Bug audit prompts — broader bug audit workflow
- Bug reproduction prompts — when reproduction itself is the blocker
- Customer service reply — reply to the user while filing
- Help center FAQ AI — preventative documentation
- User feedback clustering AI — find pattern across many reports
- App review reply AI — same triage for app store reviews