home / skills / shotaiuchi / dotclaude / debug-reproduction

debug-reproduction skill

/dotclaude/skills/debug-reproduction

This skill helps reproduce intermittent bugs and isolate triggers by creating minimal, self-contained tests and validating consistency across environments.

npx playbooks add skill shotaiuchi/dotclaude --skill debug-reproduction

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.2 KB
---
name: debug-reproduction
description: >-
  Bug reproduction and isolation investigation. Apply when attempting to
  reproduce intermittent bugs, isolate trigger conditions, create minimal
  reproduction cases, and verify consistency.
user-invocable: false
---

# Reproduction Specialist Investigation

Investigate bug reproduction to isolate triggers and create minimal, consistent reproduction cases.

## Investigation Checklist

### Trigger Isolation
- Identify the minimal set of inputs that trigger the bug
- Check for specific ordering or timing requirements to reproduce
- Verify which user actions or API calls are necessary preconditions
- Look for environmental triggers such as load, memory, or timing
- Determine if the bug requires specific data patterns or edge cases

### Minimal Reproduction
- Strip away unrelated code and configuration to isolate the bug
- Create a self-contained test case that demonstrates the failure
- Verify the reproduction case fails for the same reason as the original
- Remove dependencies one by one to find the minimal trigger set
- Document exact steps from clean state to observed failure

### Environment Reproduction
- Verify the bug reproduces across different machines and OS versions
- Check if specific runtime versions or configurations are required
- Test with clean versus populated state to isolate data dependency
- Identify whether the bug requires specific hardware or resource limits
- Verify network conditions or external service states needed to trigger

### Consistency Verification
- Run the reproduction case multiple times to measure failure rate
- Identify whether the bug is deterministic or intermittent
- Check for timing windows that make reproduction unreliable
- Verify that the reproduction case fails for the right reason
- Confirm the expected behavior by running against a known-good version

## Output Format

Report findings with confidence ratings:

| Confidence | Description |
|------------|-------------|
| High | Root cause clearly identified with supporting evidence |
| Medium | Probable cause identified but needs verification |
| Low | Hypothesis formed but insufficient evidence |
| Inconclusive | Unable to determine from available information |

Overview

This skill helps reproduce and isolate intermittent bugs to find their triggers and produce minimal, reliable test cases. It focuses on systematic isolation of inputs, environment factors, and timing to convert flaky behavior into deterministic steps. Results include a self-contained reproduction case and a confidence-rated diagnosis.

How this skill works

I run a structured investigation: isolate the exact inputs and sequence that trigger the bug, strip unrelated code and configuration to build a minimal reproduction, and test across environments to identify dependencies. I verify consistency by repeating runs, measuring failure rate, and comparing behavior against a known-good baseline. Findings are summarized with confidence ratings and concrete reproduction steps.

When to use it

  • Intermittent or flaky bugs that are hard to reproduce
  • When you need a minimal, shareable reproduction case for engineers or CI
  • To determine whether environmental factors (OS, runtime, hardware) affect the bug
  • Before filing a clear bug report or creating a patch
  • When verifying fixes across multiple platforms or versions

Best practices

  • Start from a clean state and document every step to ensure repeatability
  • Remove unrelated code and dependencies incrementally to find the minimal trigger
  • Record environment details: OS, runtime versions, hardware, resource limits, and network conditions
  • Run the reproduction multiple times and under controlled timing to measure determinism
  • Compare against a known-good version to confirm the failure reason

Example use cases

  • Reproduce a race condition that only appears under high load and create a deterministic test harness
  • Isolate a data-dependent crash by reducing the dataset to a minimal failing record
  • Verify whether a flaky integration test is caused by external service latency or local timing
  • Create a concise shell script that reproduces a memory leak for CI regression tests
  • Confirm that a reported bug is fixed across multiple OS versions before backporting

FAQ

How do you decide when a bug is reproducible enough to file a report?

When the minimal case reliably fails in a clean environment and reproduces the original failure reason, it is reproducible enough. Include steps, environment, and failure rate.

What confidence level should I expect for intermittent bugs?

Start with Low or Medium for intermittent behavior until you can reproduce consistently. Raise to High only when repeatable evidence and root-cause indicators are present.