Reproduction handoff
Packages a minimal executable failure case with enough context for another specialist to continue without repeating intake.
reproduction-reporting-handoff
See how it helpsWhen is it useful?
Use when handing an intermittent or isolated bug to its implementer.
What does it help you do?
- Records original signal, expected result and precise environment.
- Includes minimal steps, executable fixture and sanitized evidence.
- States occurrence frequency, excluded hypotheses and unresolved boundaries.
Try asking this
Hand off a pagination bug with three synthetic records, one request and a clear marker of the same failure. Make the fixture runnable in isolation and state the expected missing identifier. Another developer should reproduce the same failure without customer data or prior conversation.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Reproduction Reporting & Handoff
When to Use
Use when concluding any bug reproduction or investigation task, whether the bug was deterministically reproduced, intermittently observed, or remained unreproducible within the available environment.
Canonical 8-Part Reproduction Handoff Format
Structure every reproduction deliverable in this exact order so the diagnosing debugger and fixing developer can act immediately without re-discovering context:
- Original Signal (Reported Issue):
- Concise summary of the original report, user symptom, and reported impact.
- Expected vs. Actual Behavior:
- Expected: What should happen according to the specification or contract.
- Actual: What actually happens, quoting the exact error message, HTTP status, stack trace top frames, or corrupted UI/data state.
- Environment & Preconditions:
- Git commit SHA / version, OS/browser/runtime version, user role/permissions, required feature flags or config settings, and initial database/storage state (clean vs. dirty state).
- Minimal Reproduction Steps:
- Numbered, copy-pasteable, deterministic steps (
1. ... 2. ... 3. ...) with exact inputs/payloads that trigger the failure from the stated precondition.
- Numbered, copy-pasteable, deterministic steps (
- Executable Reproduction Case:
- File path and exact command to run the automated failing test or reproduction script (e.g.,
npx vitest run packages/server/test/repro.test.ts -t "reproduces duplicate invoice on retry"), plus the failure output it produces.
- File path and exact command to run the automated failing test or reproduction script (e.g.,
- Captured Evidence:
- Sanitized logs, stack traces, SQL queries, network request/response pairs, or screenshots proving the failure signature (with all secrets and PII redacted).
- Occurrence & Frequency Observations:
- Deterministic (
10/10attempts) vs. Intermittent (3/20attempts over 15 minutes under condition $X$), noting which variables flip the outcome betweenPASSandFAIL.
- Deterministic (
- Boundaries, Ruled-Out Hypotheses & Open Questions:
- What was tested and ruled out, what environment constraints could not be tested locally, and the exact entry point (
file:line) where the debugger should begin root-cause diagnosis.
- What was tested and ruled out, what environment constraints could not be tested locally, and the exact entry point (
When a Bug Cannot Be Reproduced
Never close or declare a bug "not a bug / works fine" just because it did not trigger locally. Document:
- The exact matrix of environments, data states, and attempts executed (
Ntrials across conditions $A, B, C$). - What environmental factor or missing telemetry differentiates the reporter's setup from the test environment.
- Specific diagnostic instrumentation or targeted questions needed to capture the next occurrence.
Included files 1
SKILL.md