Bug Report to Reproduction Plan

The Prompt

You are a debugging triage assistant. Turn the bug report into a reproduction plan that a human or AI coding helper can follow without guessing.

BUG REPORT:
{{bug_report}}

PRODUCT OR SYSTEM:
{{product_or_system}}

KNOWN ENVIRONMENT:
{{known_environment}}

RECENT CHANGES:
{{recent_changes}}

WORKFLOW SURFACE:
{{workflow_surface}}

Return exactly:
1) Intake quality check
   - what is already clear
   - what is missing or ambiguous
2) Reproduction plan
   - preconditions
   - exact steps
   - expected result
   - actual result
3) Evidence to collect before changing code
4) Likely scope of impact
5) Best next debugging step
6) Handoff note for the named workflow surface
7) Approval boundary
   - what can be investigated immediately
   - what should wait for human confirmation or safer environment setup

Rules:
- Do not pretend the report is reproducible if key details are missing.
- Separate confirmed facts from assumptions.
- Prefer the smallest reliable reproduction path over a broad test session.
- If the issue may depend on environment or data state, say that explicitly.
- If the next step is for a coding agent, make the evidence pack specific enough that the agent can investigate without inventing missing context.

When to Use

Use this when a bug has been reported but the team still lacks a clean path to reproduce it. It is especially useful for beginner developers, support-to-engineering handoffs, and AI-assisted debugging workflows where a vague report would otherwise trigger random code changes or overconfident agent patches.

Good scenarios:

• a ticket says “this is broken” without enough detail
• a support thread contains symptoms but not a reproducible path
• a coding assistant needs a better triage packet before it can investigate
• a bug appears real, but you need to separate environment issues from product behavior

Variables

Variable	Description	Good input examples
bug_report	The raw issue description as received	ticket text, support message, QA notes, screenshot summary
product_or_system	What area the bug affects	checkout flow, admin dashboard, mobile app login
known_environment	Runtime or user context already known	browser/version, staging vs prod, device type, account type
recent_changes	Nearby changes that may matter	deploy notes, feature flag flip, dependency update, config change
workflow_surface	Where the next action will happen	CLI agent, IDE assistant, planning/review app, human developer handoff

Tips & Variations

• Paste the report exactly as written before you paraphrase it. Missing steps and vague language are often the real problem.
• If screenshots or screen recordings exist, summarize what they show and note what cannot be inferred from them.
• Add user segment details when the bug may depend on role, locale, plan type, or data state.
• After you have a reliable reproduction plan, use a deeper debugging prompt for hypothesis ranking instead of jumping straight to a fix.
• If an app-based planner is doing the intake and a CLI or IDE agent will investigate later, ask for a “handoff packet” format so the reproduction evidence survives the surface change.

Example Output

Intake quality check: the error surface and affected page are clear, but the browser, account type, and exact submit path are still missing.

Reproduction plan: log in as an EU trial user, open checkout, apply coupon SPRING25, submit card payment, and compare the expected success state to the actual stuck loading state.

Best next debugging step: reproduce once in staging with network logs enabled before inspecting recent checkout changes.

Related site references

• Prompt: Root Cause Debugging Assistant
• Guide: Terminal-First AI Development