Someone files a bug report that says "the thing doesn't work." You're a QA analyst, a product manager, a developer on call, or just the person who happened to be nearest when the wheel fell off. The ticket sits in the backlog, vague and untouchable, because nobody knows what "the thing" is or when it stopped working or whether it affects one user or ten thousand.

AI bug report prompts can fix this. Not by thinking for you, but by forcing structure into the chaos before it lands on an engineer's desk.

This is a copy-paste template article. Ten prompts, each doing one specific job. Use them with ChatGPT, Claude, or whatever tool your company hasn't blocked yet. But read the safety rules first, because there's a short list of things you must never paste into any of these.

Before you touch a prompt: what not to paste into AI

This is non-negotiable. Before you copy anything into an AI tool, strip out:

Redact first. Paste second. If you're not sure whether your company has approved the AI tool you're using, check before you use it for anything work-related. The five-minute explainer on what AI can and can't do covers why this matters more than most people assume.

One practical system: keep a text file called "redaction template" open whenever you're doing bug triage. Every time you copy something to paste into AI, you paste it into the template first, swap real data for placeholders like [USER_EMAIL] or [ACCOUNT_ID], then copy the clean version. Takes about 30 seconds. Saves a potential data incident.

The reusable AI bug report formula

Every prompt in this article follows the same structure. You give AI the raw mess, you tell it the format you need, and you verify everything it produces before it goes anywhere near a ticket.

The formula:

[Raw input] + [Desired output format] + [Constraint: verified evidence only, flag uncertainty]

That last constraint is the one people skip. AI will confidently invent plausible-sounding reproduction steps, fill in missing environment details with guesses, and write severity rationale as if it has access to your error logs. It doesn't. It's pattern-matching against every bug report it's ever trained on. Useful for structure. Dangerous when mistaken for diagnosis.

Every prompt below includes an instruction to flag uncertainty rather than fill it in. Keep that line in. Remove it and you're asking the tool to make things up.

This also means the prompts are deliberately conservative. A ticket with five honest "UNKNOWN" fields is better than a ticket with five confidently wrong answers. Engineers have limited time. Sending them after a ghost because the AI guessed wrong about the environment costs more than the five minutes it takes to chase down the real data.

AI bug report prompts: 10 templates you can use right now

Prompt 1: Turn a vague complaint into a ticket

Use this when someone files a report that's basically a cry for help with no useful details.

Prompt: "I received this complaint: [paste complaint, redacted]. Turn it into a structured bug ticket with: title, summary, steps to reproduce (mark any as 'UNCONFIRMED' if not stated), expected behavior, actual behavior, environment (mark as 'UNKNOWN' if not stated), and severity (mark as 'TBD pending investigation'). Do not invent details. Flag every gap."

What you get back is a skeleton ticket with honest gaps labeled. That's the point. An engineer looking at a ticket with "UNCONFIRMED" and "UNKNOWN" fields knows exactly what to investigate first.

This prompt is especially useful when a complaint arrives through a non-technical channel: a customer email forwarded by sales, a Slack message from a client-facing team, or a voice note someone transcribed. The rawer the input, the more useful this is.

Prompt 2: Extract reproduction steps from a messy conversation

Support threads, Slack messages, and customer emails are not bug reports. They're stories. This prompt pulls the procedural steps out.

Prompt: "Here is a conversation about a bug: [paste thread, fully redacted of PII]. Extract the reproduction steps in numbered order. Use only what is explicitly stated. For any steps that seem implied but aren't confirmed, write them in italics with '(INFERRED)'. Do not add steps from general knowledge."

The "(INFERRED)" flag is doing real work here. If step three is inferred and the engineer can't reproduce the bug, they know exactly where to focus their follow-up questions instead of retrying the whole sequence from scratch.

Long support threads are the ideal input for this prompt. A 40-message Slack thread that starts with "something's broken" and ends with "oh wait it only happens on Safari" contains reproduction steps. They're just buried in three days of back-and-forth. This prompt finds them.

Prompt 3: Separate expected vs. actual behavior

This is the single most important part of any bug report and the most often missing. Engineers need to know what should have happened, not just what did.

Prompt: "Based on this description: [paste description, redacted], write two sections. Section 1: Expected Behavior, what the user or specification says should happen. Section 2: Actual Behavior, what was observed. Keep them strictly separate. If the expected behavior isn't stated, write 'Expected behavior not documented, requires product owner input.'"

That last instruction saves hours of back-and-forth. If the expected behavior genuinely isn't documented anywhere, that's a product problem, not just a bug.

It's worth noting how often this distinction exposes a disagreement rather than a defect. Sometimes what looks like a bug is actually a feature behaving as designed, but the design was wrong. The moment you write down "expected: X, actual: Y," it becomes a conversation about whether X was the right expectation in the first place. That conversation is much easier to have early, before engineering time is spent fixing the wrong thing.

Prompt 4: Summarize customer impact

Useful when you need to escalate something or prioritize a ticket against twenty others. You need a clear, honest statement of who is affected and how badly.

Prompt: "Based on this information: [paste details, redacted], write a two-paragraph customer impact summary. Paragraph 1: who is affected and what they can't do. Paragraph 2: any available data on frequency or scale (if no data is available, state that explicitly). Do not estimate numbers you don't have."

This feeds directly into severity decisions and stakeholder communication. If you've got related work in flight, the AI stakeholder update prompts can help you translate this impact summary into an exec-friendly update.

The "do not estimate numbers" instruction matters more than it looks. A casually invented "roughly 15% of users" in a customer impact summary can take on a life of its own. It ends up in a Slack escalation, then a leadership meeting, then a post-incident review. If you don't have the number, write that you don't have the number.

Prompt 5: Collect environment details

Half the bug reports that die in triage die because nobody knows what version, what browser, what operating system, or what account type the bug appeared on. This prompt generates a checklist.

Prompt: "Generate an environment details checklist for this bug: [paste brief description, redacted]. Include: OS and version, browser or app version, device type, account type or user role, geographic region if relevant, network conditions if relevant, third-party integrations if relevant. Mark each field as CONFIRMED, UNCONFIRMED, or NOT APPLICABLE. Leave blanks where data hasn't been provided."

Use this to chase down missing information before the ticket moves to development. A half-empty checklist is still better than no checklist. Send the checklist back to whoever filed the report with a request to fill in the blanks. Most people will. They just didn't know what to include the first time.

Prompt 6: Clean up screenshot and log notes

You've got a screenshot with post-it notes, a pasted error message, and three lines of log output. None of it is formatted. This prompt turns it into something an engineer can read without squinting.

Prompt: "Here are my raw notes from a bug investigation: [paste notes, fully redacted of any credentials, user data, or sensitive information]. Format them as: (1) Visual evidence summary, what screenshots show, (2) Error messages, exact text only, (3) Log snippets, formatted as code blocks, (4) What this evidence confirms, (5) What is still unverified. Do not interpret the logs technically. Just organize what I've given you."

Emphasis on "do not interpret technically." AI will happily tell you what a 502 error "probably means" for your specific infrastructure. It doesn't know your infrastructure. Keep the interpretation human.

This prompt is particularly useful for QA analysts who aren't developers. You know what you observed. You've got the screenshots. You have the error text. What you might not have is confidence that your write-up reads clearly to an engineer. This prompt handles the formatting so you can focus on the accuracy.

Prompt 7: Draft severity and priority rationale

This is where bug reports get political. Everyone thinks their bug is P1. This prompt helps you write a defensible rationale based on actual criteria rather than whoever shouted loudest.

Prompt: "Using these severity definitions: [paste your team's severity scale], and this bug information: [paste ticket details, redacted], write a severity and priority rationale. State the severity level, the primary reason for that level, and any factors that could upgrade or downgrade severity. Flag if any information needed to confirm severity is missing."

This only works if you use your team's actual severity definitions, not made-up ones. If your team doesn't have written severity definitions, that's a separate problem and fixing it is worth an afternoon.

A documented rationale also helps when a stakeholder pushes back on priority. Instead of a subjective argument, you have a written analysis tied to agreed criteria. "This is P2 because it affects less than 1% of users and a workaround exists, but it would become P1 if we confirm it's happening on enterprise accounts" is a much more useful conversation than "trust me, it's not that bad."

Prompt 8: Generate edge-case retest ideas

Once a bug is "fixed," the obvious retest is obvious. The one that bites you is the edge case nobody thought to test. This prompt generates candidates.

Prompt: "This bug was reported: [paste summary, redacted]. The proposed fix is: [paste fix description]. Generate 10 edge cases or boundary conditions to retest after the fix is applied. Focus on: different user roles, different data states, concurrent usage, partial data entry, session edge cases, and integration touchpoints. Label each as HIGH/MEDIUM/LOW priority to retest."

This feeds directly into regression planning. If you're building a full QA checklist around the fix, the AI QA checklist prompts handle the broader version.

One pattern worth knowing: the most dangerous edge cases after a bug fix are usually the ones adjacent to the original failure. If the bug happened on mobile Safari, test desktop Safari too. If it happened for admin users, check read-only users. AI is genuinely good at generating these adjacencies because it's seen enough bug reports to know where fixes tend to create new problems.

Prompt 9: Write an engineer-friendly handoff

The ticket is written. The severity is set. Now it needs to go to an engineer without a thirty-minute meeting to explain what you already know. This prompt drafts the handoff note.

Prompt: "Write a brief engineer handoff note for this bug: [paste ticket summary, redacted]. Include: what we know for certain, what we suspect but haven't confirmed, what we tried in investigation, what information is still needed from engineering, and what the first suggested investigation path is. Keep it under 200 words. Do not suggest a root cause."

"Do not suggest a root cause" is doing important work. AI will suggest one. It will sound plausible. Engineers will spend time ruling it out. Let them find the root cause.

The "what we tried in investigation" section earns goodwill with engineers fast. Nothing is more frustrating than spending twenty minutes reproducing a bug that QA already confirmed is 100% reproducible on Chrome 124, not on Firefox. Document what you already ruled out. It's not wasted effort, it's a gift.

Prompt 10: Create a regression checklist after the fix

The fix is deployed. Now you need to make sure you didn't break anything else. This prompt generates a regression checklist tied to the specific bug.

Prompt: "A bug was fixed: [paste bug summary, redacted]. The change affected: [paste affected components or code areas]. Generate a regression checklist covering: the original bug (verify it's fixed), directly related functionality, integration points with other features, and any edge cases that were identified during the bug report. Format as checkboxes. Mark any item as 'OPTIONAL' if it's lower risk given the change scope."

Pair this with AI release notes prompts when the fix ships to users. Customers and support teams shouldn't find out about a fix from a cryptic changelog entry.

This came from a book.

Don't Replace Me

200+ pages. 24 chapters. The honest version of what AI means for your career, written by someone who actually builds this stuff.

Get the Book →

How to build these prompts into your actual workflow

The prompts are useful in isolation. They're more useful as a sequence tied to your bug lifecycle.

Here's a simple mapping:

Bug reported: Prompt 1 (vague to structured), Prompt 5 (environment checklist)

Bug in triage: Prompt 3 (expected vs. actual), Prompt 4 (customer impact), Prompt 7 (severity rationale)

Bug in investigation: Prompt 2 (extract reproduction steps), Prompt 6 (clean up evidence)

Fix proposed: Prompt 8 (edge case retest ideas)

Fix ready for handoff: Prompt 9 (engineer handoff note)

Fix deployed: Prompt 10 (regression checklist)

Not every bug needs all ten. A minor UI glitch with clear reproduction steps doesn't need a customer impact summary. A payment processing failure needs everything. Match the prompt to the stakes.

The bigger discipline is consistency. When the same person writes bug reports differently every week, triage slows down. When a team uses the same structure on every ticket, engineers build pattern recognition and move faster. Prompts are how you get that consistency without making it someone's job to enforce a style guide.

What these prompts don't do

They don't diagnose the bug. They don't read your logs. They don't understand your architecture, your user base, your SLAs, or your release calendar. They produce structure, not answers.

The human value here, as Rule #7 in Don't Replace Me puts it, is knowing which failures matter. A polished ticket with a wrong severity wastes engineering time. A perfectly formatted handoff with invented reproduction steps sends engineers on a ghost hunt. AI makes things look done. That's not the same as done.

Final sign-off on every ticket is yours. Always.

The practical guide to using AI at work covers this philosophy more broadly if you want the full picture.

Frequently asked questions

Can AI write bug reports without human review?

No. AI can structure and format bug information you provide, but it can't verify reproduction steps, confirm environment details, or diagnose root causes. Every AI-generated ticket needs human review before it goes to development. Missing or invented details in a bug report waste engineering time and delay fixes.

Is it safe to paste error logs into ChatGPT or Claude?

Only if the logs are fully scrubbed of user data, credentials, and anything proprietary. Raw production logs almost always contain PII or sensitive system information. Strip everything personal and sensitive before pasting. If you're unsure whether your company allows use of the AI tool in question, check first.

What's the most common mistake in AI bug reporting?

Treating the AI output as verified information. AI will fill gaps with plausible-sounding details if you don't explicitly tell it not to. Every prompt in this article includes an instruction to flag uncertainty rather than fill it in. Keep that instruction in every time.

How do I handle bugs that involve security vulnerabilities?

Don't use AI tools for these at all. Security vulnerabilities need to go through your organization's established security disclosure process. Pasting anything touching authentication, access control, or data exposure into a third-party AI tool is a serious risk.

How do these bug report prompts relate to acceptance criteria?

They're complementary. Acceptance criteria define what "done" looks like before development. Bug reports capture what went wrong after something ships. If you're finding bugs that point back to unclear acceptance criteria, the AI acceptance criteria prompts help close that loop upstream.

What if my team doesn't have standard severity definitions?

Then your severity is whatever the most senior person in the room says it is on any given day, which is a great way to have permanent firefighting culture. Write a simple four-level scale (Critical/High/Medium/Low) with one-sentence definitions for each. It takes an hour. Prompt 7 works much better with it.