systematic-debugginglisted

# Systematic Debugging Find the root cause before changing code. Do not patch symptoms. ## Core Rule No fixes without root cause evidence first. Use this skill for test failures, production bugs, build failures, performance problems, integration issues, and any behavior you cannot explain. ## Workflow 1. Read the error carefully. - Capture the exact message, stack trace, file, line, route, status, or failing assertion. - Do not skip warnings that appear near the failure. 2. Reproduce the issue. - Record exact steps or the exact command. - If it is flaky, collect more data before guessing. 3. Check recent changes. - Review the diff, recent commits, config changes, dependency changes, and environment differences. 4. Trace the failing data or control flow. - Find where the bad value, state, request, or assumption first appears. - In multi-component systems, add temporary diagnostics at each boundary. - For deep call stacks, read `references/root-cause-tracing.md`. 5. Compare with a working pattern. - Find similar working code in the repo. - List the meaningful differences before editing. 6. State one hypothesis. - Write the root cause as: "I think X fails because Y." - Test one variable at a time. 7. Add the smallest proof. - Prefer a failing test, focused repro command, log probe, or trace query. 8. Fix the source. - Make the smallest change that addresses the root cause. - Verify the original repro and a scoped regression chec