01
Normalize the report
Turn the original wording into a neutral failure statement and expose unsupported claims.
Made for Engineers
Triage an Ambiguous Bug Report
Also useful for: people in Software Engineering
45 min
Advanced
Software Engineering
Engineer
Build Professional Skills
Career outcome:
Avoid Professional Risk
Convert a thin bug report into a focused investigation plan without making random code changes.
We'll use them to write your prompt.
Completed ✓
Make Your Play
Give us the situation. We’ll build the prompt.
Replace guesswork with a structured triage path that separates facts from assumptions, finds the smallest useful reproduction, and prioritizes tests by information value.
Your answers save as you type.
What you'll do
This is the plan inside your prompt. Add your details first. Then follow these steps with ChatGPT or Claude.
02
Ask decision-changing questions
Find the smallest set of missing details that could materially change reproduction, impact, or priority.
03
Build the minimal reproduction
Reduce the reported flow to explicit conditions and one observable pass or fail result.
04
Compare environments
Use a known-good control to isolate variables instead of changing several conditions at once.
05
Tighten the failure signal
Define exactly how the test proves success or failure.
06
Bound the impact
Separate an annoying edge case from a broad or unsafe failure.
07
Build the change timeline
Align the first known failure with releases and operational changes while avoiding false causal claims.
08
Rank fault-area hypotheses
Use current evidence to narrow the search without committing to a favorite explanation too early.
09
Choose the next test
Select the safest check that removes the most uncertainty for the least effort.
10
Write the triage brief
Package the evidence and decision so investigation can continue without repeating the same discovery work.
Make Your Play
Triage an Ambiguous Bug Report
Tell us what the prompt needs to know
Start with the questions below. Each answer personalizes the playbook and builds the prompt you’ll use at the end.
Your situation
Paste the original report, including its title, description, comments, and any reported steps.
0/10000
Describe the affected service, application flow, dependencies, and relevant architecture.
0/10000
State what should happen and name the source of that expectation when known.
0/10000
Describe what happens instead, using exact messages, status codes, timing, or visible symptoms when available.
0/10000
List known versions, devices, regions, accounts, feature flags, data states, and environments.
0/10000
List logs, metrics, traces, screenshots, test results, and failed investigation attempts already available.
0/10000
Describe the affected population, frequency, severity, workaround, and any data or security concern.
0/10000
List recent deployments, configuration edits, migrations, dependency updates, or traffic changes that could overlap with the first occurrence.
0/10000
Select the current response level.
List time limits, access restrictions, unsafe actions, change freezes, or systems that mustn't be disturbed.
0/10000
This playbook was updated. Review your inputs before copying.
What you'll do
Check a step when you finish it.
01
Normalize the report
Turn the original wording into a neutral failure statement and expose unsupported claims.
02
Ask decision-changing questions
Find the smallest set of missing details that could materially change reproduction, impact, or priority.
03
Build the minimal reproduction
Reduce the reported flow to explicit conditions and one observable pass or fail result.
04
Compare environments
Use a known-good control to isolate variables instead of changing several conditions at once.
05
Tighten the failure signal
Define exactly how the test proves success or failure.
06
Bound the impact
Separate an annoying edge case from a broad or unsafe failure.
07
Build the change timeline
Align the first known failure with releases and operational changes while avoiding false causal claims.
08
Rank fault-area hypotheses
Use current evidence to narrow the search without committing to a favorite explanation too early.
09
Choose the next test
Select the safest check that removes the most uncertainty for the least effort.
10
Write the triage brief
Package the evidence and decision so investigation can continue without repeating the same discovery work.
Fill in the fields above to generate your prompt preview.
Assembled prompt
Beginner instructions
Start with the information already in the ticket. If a field is unknown, write “Unknown” rather than guessing. Run only checks you understand and can safely reverse.
Advanced instructions
Add trace IDs, release markers, feature flag states, dependency versions, data-shape differences, and known-good controls when available. Prefer tests that eliminate multiple hypotheses without changing production state.
Use this when
You receive a bug report with missing steps, uncertain impact, conflicting observations, or no clear place to start investigating.
You'll need
- Bug report
- System context
- Expected behavior
- Observed behavior
- Environment details
- Existing evidence
- Known scope
- Recent changes
- Urgency
- Investigation constraints
You'll get
- A failure statement separated into facts, claims, assumptions, and unknowns
- A confirmed reproduction or a documented reproduction blocker
- Affected and unaffected conditions compared
- Impact bounded across severity, scope, and recoverability
- Fault-area hypotheses ranked by evidence
- One safe next investigation step assigned
By the end of this playbook
You will have:
- A failure statement separated into facts, claims, assumptions, and unknowns
- A confirmed reproduction or a documented reproduction blocker
- Affected and unaffected conditions compared
- Impact bounded across severity, scope, and recoverability
- Fault-area hypotheses ranked by evidence
- One safe next investigation step assigned
Examples
Progress 1 of 10