Jamie

Jamie — replicate the report to confirm the bug

The claim · the rig · the verdict.

Jamie takes a bug report and tries to make it happen — on purpose, reliably — before anyone tries to fix it. A report is a claim, not a fact: "the app crashes when I upload a CSV" is a hypothesis until you can pull the trigger yourself. Jamie's job is to convert that claim into a minimal, reliable reproduction and stamp it with a verdict, Mythbusters-style:

• CONFIRMED — reproduced reliably; you hold a minimal, one-command repro (and a reliability rate if it's intermittent).
• PLAUSIBLE — reproduces only under conditions you had to discover, or a real adjacent defect exists but not the exact report.
• BUSTED — could not reproduce after faithfully recreating the conditions and escalating. Not "there's no bug" — "the report as written doesn't reproduce" — and you say why.

The whole discipline rests on one rule: a failed reproduction is evidence about a mismatched condition, not proof the reporter is wrong. Most "can't reproduce" is one unmatched variable — the wrong version, the wrong data, the wrong platform, the wrong timing — away from a perfect repro.

Six moves:

• The report is a claim. Turn the prose into a falsifiable statement: exact preconditions, steps, expected vs actual, and the environment it was seen in. Write down what the report doesn't say (the unstated conditions).
• Match their world, not yours. Recreate the version they hit (checkout that release/commit, not latest), their config/flags, their data/inputs, their platform/OS/arch, locale/timezone, account/permissions/state, concurrency/scale.
• Build the rig and capture the failure. Reproduce the full scenario until it fails, and capture the failure as an artifact (a log, a crash, a diff) — not "I think I saw it."
• Minimize. Shrink the working repro to the smallest thing that still fails (delete-and-retest). The deliverable is a repro someone else can run in one step.
• Quantify reliability. 100% or intermittent? Run it N times and report the rate (e.g. 7/20). Intermittent is a number, not a shrug.
• Never bust on the first miss. Before declaring BUSTED, escalate: vary the condition you most likely mismatched, ask the reporter for the one missing variable, and check whether it's already been fixed.

When to use

• triaging an incoming issue / bug report before any work starts
• "can't reproduce it" / "works on my machine" — the maintainer's side of that
• an intermittent / flaky / "happens sometimes" report
• before assigning, fixing, or closing a bug (close as not-repro only with evidence and a stated reason)
• you want a minimal repro or a failing regression test to anchor the fix
• confirming a security report or a customer escalation is real before you spend a team on it

When NOT to use

• The bug is already reproducing reliably in front of you — you have the repro; skip to root-cause (sherlock) or just fix it.
• It's your own freshly-written code failing your own test — that's plain debugging; the repro is already in hand → debug it directly (superpowers:systematic-debugging / sherlock).
• You're confirming your own work is complete — that's the opposite direction; use superpowers:verification-before-completion.
• A feature request / design discussion — there's no defect to replicate.
• You can already trigger it on demand and only need to know why it's flaky — that's sherlock. Jamie's job ends once k/N is a runnable gate; explaining the mechanism is sherlock's.

The replication loop (claim → rig → verdict)

1. EXTRACT THE CLAIM. Rewrite the report as a falsifiable claim: preconditions · steps · expected · actual · environment-seen-in. Mark every unstated condition (version? data? platform? scale? account?) — those gaps are your first work, because they're where "can't reproduce" hides.
2. MATCH THE CONDITIONS. Recreate the reporter's world deliberately, highest- leverage variables first: the version they actually hit (not main), config & feature flags, the real input/data (theirs, or a faithful synthetic), platform/OS/arch, locale/timezone, account/permissions/pre-existing state, concurrency/load/scale, network. (Dimension checklist + why each matters: references/cant-reproduce-playbook.md.)
3. BUILD THE RIG, FAIL IT, MINIMIZE, QUANTIFY. Reproduce the full scenario and capture the failure artifact. Then minimize to the smallest reliable repro (delete-and-retest each element). Then quantify: run it N times and record the rate — k/N. The output is a one-command repro + its reliability.
4. VERDICT + HANDOFF.
   • CONFIRMED → reliable minimal repro in hand → hand it to sherlock (find the cause) and/or andrej (drive the fix — the repro is the gate).
   • PLAUSIBLE → reproduces only under discovered conditions, or an adjacent defect is real → document the conditions; narrow further or hand off with caveats.
   • BUSTED → faithful recreation and escalation both failed → classify why (already-fixed / user-error / env-specific-to-reporter / missing-info / below-threshold-intermittent / misdescribed) and return the evidence + the one missing variable you need from the reporter. Never bust on the first miss.

Full detail (claim extraction, the condition-match checklist, minimization, measuring intermittency, the escalation ladder before BUSTED): references/replication-method.md. Verdict definitions and evidence bars: references/verdict-rubric.md.

Mental model: Mythbusters

• The claim, the rig, the verdict. You don't "look into" a report — you build a controlled rig that recreates it, run it, and rule it confirmed / plausible / busted with evidence on tape.
• If it ain't reproduced, it ain't a bug yet — it's a claim. Confirmation is a repro you can run on demand, not a story that sounds plausible.
• Replicate the conditions, not your assumptions about them. "It crashes on upload" — which version, which file, how big, what encoding? You match the reporter's actual world; you don't substitute the convenient one.
• BUSTED is a verdict about the report, not the reporter. It means "as written, this doesn't reproduce — here's what I tried and the variable I'm missing," never "you're wrong."

Worked example: the CSV crash that "works on my machine"

Report: "App crashes whenever I upload a CSV."

1. EXTRACT. Claim = "uploading a CSV crashes the app." Unstated conditions: which version? which CSV (size/encoding/content)? which platform? That's the whole ballgame.
2. First naive attempt (the trap). On main with a tidy 100-row sample CSV → works fine. The tempting move is BUSTED. Don't — you matched none of the reporter's conditions.
3. MATCH. The report was filed against v2.3.1 (you were on main, where it may already be fixed), and the reporter's file is a 1.2 M-row export with a UTF-8 BOM and CRLF line endings. Rebuild the rig: git checkout v2.3.1, generate a CSV with BOM + CRLF at 1.2 M rows, upload → crash (OOM in the parser).
4. MINIMIZE. Delete-and-retest: BOM removed → still crashes (not it). CRLF → LF → still crashes (not it). Drop to 100k rows → no crash; crashes reliably above ~800k rows. Minimal repro: "on v2.3.1, upload a ≥800k-row CSV."
5. QUANTIFY. 20/20 crashes at 1.2 M rows — deterministic.
6. VERDICT: CONFIRMED. And a key note for handoff: it does not reproduce on main → likely already fixed (find the commit and verify; if so the fix is "backport / upgrade," not a new patch). Hand the minimal repro to sherlock (cause: unbounded in-memory parse) / andrej (gate: crash-free at 2 M rows).

The lesson: the first "works for me" was a version + data mismatch, not a busted report. A real, deterministic bug was one matched condition away.

Quick start

1. Open a repro report and extract the claim — and the unstated conditions:

   cp skills/jamie/templates/repro-report.md repro-report.md
   # fill: preconditions · steps · expected · actual · environment; list what the report DOESN'T say
   

2. Match the reporter's conditions — the version they hit first, then config, the real data, platform, locale/tz, account/state, scale/timing (the dimension checklist + why each one breaks repro: references/cant-reproduce-playbook.md).

3. Build the rig → fail it → minimize → quantify. Capture the failure artifact, shrink to a one-command repro, run it N times for a k/N reliability rate.

4. Stamp the verdict. CONFIRMED / PLAUSIBLE / BUSTED (definitions + evidence bar: references/verdict-rubric.md) — never BUSTED on the first miss; escalate first. Hand a CONFIRMED minimal repro to sherlock / andrej.

References

• references/replication-method.md — the loop in depth: extracting a falsifiable claim from prose, the condition-match strategy (highest-leverage variables first), building & minimizing the repro, measuring intermittency (k/N, and how many runs you need), and the escalation ladder you must climb before declaring BUSTED.
• references/cant-reproduce-playbook.md — the catalogue of why a real bug won't reproduce for you, as Symptom → likely-mismatch → fix, across every condition dimension (version/build, config, data, platform/arch, locale/timezone, concurrency/scale, state/ordering, cache, network, permissions, the reporter's specific account, Heisenbug-under-observation, already-fixed-on-main, only-in-prod).
• references/verdict-rubric.md — CONFIRMED / PLAUSIBLE / BUSTED: the precise definition and evidence bar for each, the sub-classes of BUSTED (already-fixed / user-error / env-specific / missing-info / below-threshold / misdescribed-but- adjacent), and the correct handoff for each verdict.

Templates

• templates/repro-report.md — a fill-in: the extracted claim (preconditions · steps · expected · actual · env), the conditions matched vs unmatched, the minimal one-command repro, the reliability rate k/N, the verdict + its evidence, and the handoff (to sherlock/andrej, or back to the reporter for the one missing variable).

Relationship to sherlock, andrej, systematic-debugging & terry

Jamie is the reproduce-before-you-believe front door; it produces the artifact the other skills consume:

• sherlock answers "why?"; Jamie answers "is it real, and how do I trigger it?" — the step before sherlock. A CONFIRMED minimal repro is the input to sherlock's elimination (and the thing that lets you eliminate by evidence).
• andrej's "reproduce the failure before you fix it" is a single line; Jamie is that step expanded into a discipline. Jamie's confirmed repro and its reliability rate become andrej's metric/gate (e.g. failures_per_20_runs: 7 → 0).
• superpowers:systematic-debugging is the overall reproduce → isolate → fix flow; Jamie is its reproduction stage — so if you already hold a reliable repro, enter systematic-debugging (or sherlock) directly and skip Jamie. A CONFIRMED repro converts directly into the failing regression test TDD wants written first.
• terry: at fleet scale, Jamie is the issue-queue triage — confirm or bust each inbound report, then dispatch the CONFIRMED ones (each with its minimal repro) as scoped worker tasks.