Triage Issues Into Bug or Change
It sorts an issue report into a bug or a deliberate change, and gives you a test idea to match. It works because it sets a clear rule: any current failure counts as a bug, even when the reporter also asks for a spec update.
Worked in our testThe Bug classification, one-sentence reason, two evidence lists and three-sentence test idea are all correct. It strays in two places. The failure list includes a quote from the documented behaviour, which isn't in the issue text. It also pads that list with user impact and trigger lines that aren't failures. The test idea also bundles a second assertion and a documentation note, where the prompt asked for one test idea.
The prompt
Act as a careful senior engineer who triages software issue reports.
Task: Decide whether the issue below is a bug (something currently behaves wrongly and needs reproducing) or a change (a deliberate new requirement with nothing broken today).
Issue: {issue_text}
Current documented behaviour: {documented_behaviour}
Steps:
1. List every sign of a current runtime failure in the issue, such as errors, crashes, wrong output or regressions. Quote the exact words.
2. List every sign of a deliberate requirement change, such as new wording, new features or updated policy.
3. If any runtime failure exists, classify it as a bug, even if the reporter also says the documentation or spec should be updated.
4. Otherwise classify it as a change.
5. Write one test idea. For a bug, describe a failing test that reproduces it. For a change, describe a test that proves the new requirement.
Output:
Classification: Bug or Change, then a one-sentence reason. Then "Evidence" with two short bullet lists, then "Test idea" in no more than three sentences.
Change the parts in curly braces. Use it when your issue tracker is filling up with mixed reports and you need to decide what to fix first and how to prove it.
What happened when we ran it
We sent
Act as a careful senior engineer who triages software issue reports. Task: Decide whether the issue below is a bug (something currently behaves wrongly and needs reproducing) or a change (a deliberate new requirement with nothing broken today). Issue: Since last week's update, exporting an invoice to PDF crashes with 'KeyError: vat_rate' whenever the customer is based outside the UK. The export worked fine in version 2.3. We should also update the spec so it says VAT rate is optional for overseas customers. Several customers have emailed support about it. Current documented behaviour: The invoice export produces a PDF for every customer. For UK customers the VAT rate is shown on each line item. The spec does not say what should happen for overseas customers. Steps: 1. List every sign of a current runtime failure in the issue, such as errors, crashes, wrong output or regressions. Quote the exact words. 2. List every sign of a deliberate requirement change, such as new wording, new features or updated policy. 3. If any runtime failure exists, classify it as a bug, even if the reporter also says the documentation or spec should be updated. 4. Otherwise classify it as a change. 5. Write one test idea. For a bug, describe a failing test that reproduces it. For a change, describe a test that proves the new requirement. Output: Classification: Bug or Change, then a one-sentence reason. Then "Evidence" with two short bullet lists, then "Test idea" in no more than three sentences.
The model replied
**Classification: Bug.** Exporting an invoice to PDF crashes with a KeyError for non-UK customers, which is a regression from 2.3 and contradicts the documented behaviour that export produces a PDF for every customer.
**Evidence**
Runtime failure signs:
- "exporting an invoice to PDF crashes with 'KeyError: vat_rate'"
- "whenever the customer is based outside the UK" (consistent, reproducible trigger)
- "Since last week's update" and "The export worked fine in version 2.3" (regression)
- "Several customers have emailed support about it" (user impact)
- Documented behaviour: "The invoice export produces a PDF for every customer" (the crash violates this)
Requirement change signs:
- "We should also update the spec so it says VAT rate is optional for overseas customers" (a spec clarification, since the spec is currently silent on overseas customers; it does not remove the failure)
**Test idea**
Create an invoice for a customer with a non-UK address and no `vat_rate` in the data, call the PDF export, and assert that it returns a valid PDF without raising `KeyError` (this fails on the current build). Also assert that a UK customer's PDF still shows the VAT rate on each line item. The spec update can be handled as a separate documentation task.
Run on Claude Sonnet 5.5, 01 Nov 2026. Automatic check: 4 out of 5.
Mentioned for
Claude, ChatGPT, Gemini
Where it came from
Found on GitHub, shared by promptdriven: promptdriven/pdd.
This is our own version of the idea, written and tested by us. The original may differ.