From godmode
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
npx claudepluginhub noobygains/godmode --plugin godmodeThis skill uses the workspace's default tool permissions.
Guessing at fixes wastes time and introduces new defects. Quick patches mask underlying problems.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Guessing at fixes wastes time and introduces new defects. Quick patches mask underlying problems.
Core principle: ALWAYS identify root cause before attempting any fix. Treating symptoms is failure.
No exceptions. No workarounds. No shortcuts.
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you have not completed Phase 1, you are not authorized to propose fixes.
Apply to ANY technical issue:
Especially important when:
Do not skip when:
You MUST complete each phase before advancing to the next.
BEFORE attempting ANY fix:
Read Error Messages Thoroughly
Reproduce Reliably
Examine Recent Changes
Gather Evidence in Multi-Component Systems
WHEN the system has multiple components (CI -> build -> signing, API -> service -> database):
BEFORE proposing fixes, add diagnostic instrumentation:
For EACH component boundary:
- Log what data enters the component
- Log what data exits the component
- Verify environment/config propagation
- Check state at each layer
Run once to collect evidence showing WHERE it breaks
THEN analyze evidence to identify the failing component
THEN investigate that specific component
Example (multi-layer system):
# Layer 1: Orchestrator
echo "=== Orchestrator state: ==="
echo "TOKEN: ${TOKEN:+SET}${TOKEN:-UNSET}"
# Layer 2: Build script
echo "=== Build environment: ==="
env | grep TOKEN || echo "TOKEN not in environment"
# Layer 3: Signing module
echo "=== Certificate state: ==="
security list-keychains
security find-identity -v
# Layer 4: Actual operation
codesign --sign "$IDENTITY" --verbose=4 "$ARTIFACT"
This reveals: Which layer fails (secrets -> orchestrator OK, orchestrator -> build FAIL)
Trace Data Flow
WHEN the error is deep in the call stack:
See root-cause-tracing.md in this directory for the complete backward tracing method.
Short version:
Find the pattern before fixing:
Locate Working Examples
Compare Against References
Identify Differences
Understand Dependencies
Scientific method:
Form a Single Hypothesis
Test Minimally
Verify Before Continuing
When You Do Not Know
Fix the root cause, not the symptom:
Create a Failing Test Case
godmode:test-first skill for writing proper failing testsImplement a Single Fix
Verify the Fix
If the Fix Does Not Work
If 3+ Fixes Failed: Question Architecture
Pattern indicating an architectural problem:
STOP and question fundamentals:
Discuss with your human partner before attempting more fixes
This is NOT a failed hypothesis -- this is a flawed architecture.
If you catch yourself thinking:
ALL of these mean: STOP. Return to Phase 1.
If 3+ fixes failed: Question the architecture (see Phase 4, step 5)
Watch for these redirections:
When you see these: STOP. Return to Phase 1.
| Rationalization | What Is Actually True |
|---|---|
| "Issue is simple, process not needed" | Simple issues have root causes too. The process is fast for simple bugs. |
| "Emergency, no time for process" | Systematic diagnosis is FASTER than guess-and-check flailing. |
| "Just try this first, then investigate" | The first fix sets the pattern. Do it right from the start. |
| "I'll write the test after confirming the fix works" | Untested fixes do not hold. Test first proves it. |
| "Multiple fixes at once saves time" | Cannot isolate what worked. Creates new bugs. |
| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. |
| "I see the problem, let me fix it" | Seeing symptoms is not the same as understanding root cause. |
| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern, do not fix again. |
| Phase | Key Activities | Success Criteria |
|---|---|---|
| 1. Root Cause | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
| 2. Pattern | Find working examples, compare | Identify differences |
| 3. Hypothesis | Form theory, test minimally | Confirmed or new hypothesis |
| 4. Implementation | Create test, fix, verify | Bug resolved, tests pass |
If systematic investigation reveals the issue is truly environmental, timing-dependent, or external:
But: 95% of "no root cause" cases are incomplete investigation.
These methods are part of fault diagnosis and available in this directory:
root-cause-tracing.md - Trace bugs backward through the call stack to find the original triggerdefense-in-depth.md - Add validation at multiple layers after finding root causecondition-based-waiting.md - Replace arbitrary timeouts with condition pollingRelated skills:
From diagnosis sessions: