domains / families / software-engineering / systematic-debugging

systematic-debugging

combined

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes Root-cause route for actual bugs, failing tests, build errors, crashes, stack traces, and unexpected behavior. Do not use for test-first/TDD feature work, test-report packaging, review-feedback handling, or final completion evidence.

When to use

• Test failures
• Bugs in production
• Unexpected behavior
• Performance problems
• Build failures
• Integration issues
• Under time pressure (emergencies make guessing tempting)
• "Just one quick fix" seems obvious

When not to use

• Temporary mitigation and root-cause repair are different outcomes; record both when an incident requires immediate containment.
• Logging can expose secrets or personal paths. Use allowlisted summaries and inspect captured artifacts before sharing.
• The polluter helper runs the project’s test command and can execute project code; use an isolated fixture/checkout and verify the runner accepts a file argument.
• The waiting examples require domain adapters and cannot make every race impossible. Reproduce the actual timeout/error path.

Skill page

Conflict

The four copies share the same four-phase skeleton, but they disagree on the core principle and on the multi-component instrumentation step. obra/superpowers and LeoYeAI/openclaw-master-skills enforce a strict 'no fixes without root cause' rule and use a four-layer diagnostic example that logs environment state and performs a live codesign. foryourhealth111-pixel/Vibe-Skills adds a routing boundary that excludes TDD and report packaging. sickn33/agentic-awesome-skills explicitly permits emergency mitigation/rollback during an incident and changes the instrumentation to redact secrets and use read-only artifact verification. Because the sickn33 copy relaxes the 'Iron Law' and the others do not, crowning one copy would hide a real alternative for incident response.