systematic-debugging
Systematic Debugging
Overview
Random fixes waste time and create new bugs. Quick patches mask underlying issues.
Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
Violating the letter of this process is violating the spirit of debugging.
The Iron Law
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
When to Use
More from faulkdev/github-copilot-superpowers
minimalist-surgical-development
Use when editing an existing codebase and the goal is minimal, standard, and non-invasive changes - prioritizes simplest solution, standard libraries first, and surgical modification without unsolicited refactors
34uncertainty-verification
Use when providing exact commands, flags, config keys, file paths, API details, standards, or version-specific behavior - enforces verification via official docs (Context7/web fetch), explicit citations, and bans assumption-based specifics
20investigation-mode
DEPRECATED: See systematic-debugging for current implementation.
14verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
14root-cause-tracing
Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior
13task-direction-approval
Use when considering switching libraries/tools, changing architecture, or replacing automation with manual workarounds - explains root cause, offers 2-3 options with trade-offs, and requests explicit user choice
13