PromptDev

Write a bug report

Messy observations become a report an engineer can act on: numbered steps, expected vs actual, severity, and the gaps listed as questions.

Last updated

Fill in the blanks

Assembled in your browser — nothing you type is stored or sent anywhere.

Your prompt

Turn these messy observations into a proper bug report: [paste the raw notes, Slack messages, or user report here]. Structure it as: a title naming the symptom and where it happens (like "Checkout: 500 after applying an expired coupon on mobile Safari", never "bug in checkout"); numbered reproduction steps in the order they must happen; Expected vs Actual behaviour, stated as two separate lines; Environment (browser, OS, app version, account type — whatever is known); and a severity rating with one sentence justifying it (who's affected, how often, whether there's a workaround). If the observations don't give enough to fill a section — reproduction steps, environment, or frequency — list what's missing as explicit questions at the end instead of inventing plausible-sounding steps.

Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.

Why this prompt works

  • →Requiring a symptom-and-location title instead of a vague one is what keeps a bug tracker searchable months later, rather than full of reports all called "issue with form."
  • →Splitting Expected vs Actual into two explicit lines forces the report to state the assumption being violated — the part a rushed bug report skips most often.
  • →Listing missing information as questions, instead of filling gaps with invented steps, stops a report from shipping false reproduction steps that send an engineer chasing the wrong scenario.

Part by part

a title naming the symptom and where it happens
The title is what gets scanned in a list of two hundred issues. A symptom plus a location is searchable; a category is not.
numbered reproduction steps in the order they must happen
Ordering is the whole value. A reproduction that cannot be followed exactly is an anecdote, and it is why most bugs get closed as not reproducible.
Expected vs Actual behaviour, stated as two separate lines
Separating them forces both to be stated. Written as one sentence, the expectation is usually implied and the reader has to guess it.
a severity rating with one sentence justifying it
A number alone is an opinion. Who is affected, how often, and whether a workaround exists is what makes it arguable rather than assertive.
list what's missing as explicit questions
The alternative to inventing reproduction steps, which is the most damaging thing a generated bug report can do — it sends someone chasing a path nobody took.

Common mistakes

  • Write a bug report for this issue.

    Fills every section whether or not the information exists, so the environment and reproduction steps are plausible inventions. A developer then fails to reproduce and closes it, and the real bug survives.

  • Make this bug report more professional.

    Improves the prose and leaves the structure alone, so a report missing its reproduction steps is now a well-written report missing its reproduction steps.

  • Summarise these observations as a bug.

    Produces a paragraph, which is the format bug reports exist to replace. The structure is what makes a report triageable without reading it in full.

Questions

Why does the title matter so much?

Because it is nearly all anyone reads. "Bug in checkout" is invisible in search and unrankable in triage; a title naming the symptom, the surface and the condition lets someone judge severity without opening it.

What if I do not know the environment?

Say so rather than omitting the section. "Reported on mobile, browser unknown" tells a triager something; a missing section reads as an oversight and invites an assumption that it worked everywhere else.

Why separate expected from actual?

Because a surprising number of bugs turn out to be a disagreement about what should happen. Writing both down separately surfaces that immediately, and occasionally resolves the issue without any code changing.

Should I include a severity if I am not sure?

Yes, with the justification. A rating you can argue with is more useful than none, and the sentence explaining it is what lets a triager adjust it rather than starting the assessment from nothing.

Related in Prompts