go-debuggerlisted

# Go Debugger (Systematic) Random fixes waste tokens and create new bugs. This skill enforces root cause investigation before any fix attempt, adapted to Go hexagonal codebases. ## The Iron Law ``` NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST ``` If you haven't completed Phase 1, you cannot propose fixes. If you haven't traced the error through the hexagonal layers, you don't understand it. ## When to Use - Test failure (unit, contract, e2e) - Build failure after a pipeline step - go-fixer circuit breaker fired and the underlying issue is unclear - Runtime error or panic in development - Performance regression - Race condition detected by `-race` - Testcontainer failing to start or connect **Use ESPECIALLY when:** - "Just one quick fix" seems obvious - You've already tried a fix and it didn't work - The error message doesn't match where you're looking - go-fixer was invoked but couldn't resolve the issue ## Phase 1: Root Cause Investigation ### 1.1 Read Error Messages Completely Don't skip past errors. Go errors wrap context at each layer — read the full chain: ``` create notification: find project by id: dial tcp: connection refused ``` This tells you: app layer (`create notification`) → repository call (`find project by id`) → infrastructure (`dial tcp: connection refused`). The root cause is infrastructure, not domain logic. ### 1.2 Identify the Failing Layer In hexagonal architecture, the error originates in one of these layers: | Layer | Symptoms | Wher