systematic-debugging

Topics in the source

• Systematic Debugging
• Overview
• The Iron Law
• The Feedback Loop Rule
• When to Use
• The Four Phases
• Phase 1: Root Cause Investigation
• 1. Read Error Messages Carefully

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. Method adapted from the public superpowers debugging flow (MIT); the feedback-loop rule, ranked falsifiable hypotheses, and rule-of-three escalation were extended here. If you haven't completed Phase 1, you cannot propose fixes. The feedback loop is the debugging work. Before reading code to build a theory, create or identify a tight command that can go red on the user's exact symptom and green when the bug is fixed. A tight loop is fast, deterministic, agent-runnable, and specific enough to catch this bug — not merely "doesn't crash". When a clean repro is hard, spend disproportionate effort building the loop. Guessing without a red-capable loop is the failure mode this skill exists to prevent. Use for ANY technical issue: Test failures Bugs in production Unexpected behavior Performance problems Build failures Integration issues Use this ESPECIALLY when: Under time pressure (emergencies make guessing tempting) "Just one quick fix" seems

This is an excerpt. Refer to the complete source and its current requirements.