reproduce-reduce-regress
Systematic workflow for debugging by reproducing bugs with real data, reducing test cases to minimal examples, and adding regression tests
When & Why to Use This Skill
This Claude skill provides a systematic 'Reproduce, Reduce, Regress' workflow designed to streamline the software debugging process. It guides developers through capturing real-world bug data, isolating minimal failing test cases via binary search, and establishing robust regression tests to ensure long-term code stability and prevent bug re-emergence.
Use Cases
- 1. Production Bug Reproduction: Efficiently capturing and using real-world data to recreate failing scenarios in a controlled environment for accurate troubleshooting.
- 2. Test Case Minimization: Applying systematic reduction techniques to transform large, noisy inputs into the smallest possible failing examples to pinpoint root causes.
- 3. Regression Suite Development: Building a comprehensive set of passing and failing test variants that document expected behavior and protect against future regressions.
- 4. Root Cause Analysis: Comparing minimal passing and failing cases to identify the specific logic or data state changes that trigger software defects.
| name | reproduce-reduce-regress |
|---|---|
| description | Systematic workflow for debugging by reproducing bugs with real data, reducing test cases to minimal examples, and adding regression tests |
Reproduce, Reduce, Regress
When debugging a bug, follow this workflow:
1. Reproduce
Goal: Get a failing test that demonstrates the bug using REAL data.
- Copy the EXACT input that triggers the bug (don't paraphrase or simplify yet)
- Use the EXACT types/structs from the failing code
- Verify the test actually fails with the same error message
2. Reduce
Goal: Find the MINIMAL input that still triggers the bug.
- Create MULTIPLE test variants, don't comment things in/out
- Name them descriptively:
test_minimal_one_field,test_with_queries, etc. - Binary search: remove half the input, see if it still fails
- Keep narrowing until you find the smallest failing case
- Also find a PASSING case that's as close as possible to the failing one
The difference between your minimal failing case and your minimal passing case IS the bug.
3. Regress (Regression Tests)
Goal: Ensure the bug never comes back.
- Keep ALL your test variants - both passing and failing
- The failing ones become regression tests after the fix
- The passing ones document expected behavior
- Name tests after the issue number:
test_issue_1356_*
Anti-patterns
❌ Commenting code in/out to test different scenarios ❌ Modifying a single test repeatedly ❌ "Simplifying" input without verifying the bug still reproduces ❌ Deleting test variants after finding the bug ❌ Theorizing about what MIGHT cause the bug before reproducing
Example Structure
// Minimal failing case
#[test]
fn test_issue_1356_fails_without_queries_default() { ... }
// Minimal passing case (shows the workaround)
#[test]
fn test_issue_1356_passes_with_queries_default() { ... }
// Original reproduction from user's code
#[test]
fn test_issue_1356_full_reproduction() { ... }