debugging
Root cause analysis and debugging protocols. Use when encountering errors, test failures, unexpected behavior, stack traces, or when code behaves differently than expected.
Works with
--- name: debugging description: Root cause analysis and debugging protocols. Use when encountering errors, test failures, unexpected behavior, stack traces, or when code behaves differently than expected. license: MIT --- # Debugging Systematic approach to root cause analysis and debugging. ## When to Use - Encountering errors or exceptions - Test failures that need investigation - Unexpected behavior in code - Stack traces or error messages - Code behaving differently than expected - Performance issues or bugs ## Core Principles - **Evidence-based**: Base diagnosis on error messages, logs, and reproducible steps - **Systematic**: Follow structured debugging process - **Minimal fixes**: Implement smallest change that resolves issue - **Verify solutions**: Confirm fix works and doesn't introduce regressions ## Debugging Process Follow systematic debugging process: 1. Capture error information (message, stack trace, logs, environment) 2. Identify reproduction steps (minimal steps, conditions, edge cases) 3. Isolate failure location (function/module, recent changes, dependencies) 4. Form and test hypotheses (evidence-based, systematic testing, debug logging) 5. Implement minimal fix (smallest change, preserve behavior, follow patterns) 6. Verify solution (issue resolved, no regressions, tests pass) See `references/root-cause-analysis.md` for detailed methods. ## Strategic Debug Logging Add debug logging to entry/exit points, state transitions, conditional branches, external API calls, and data transformations. Remove after issue resolved unless it provides ongoing value. ## Error Pattern Recognition Common patterns: null/undefined errors, type errors, timing issues, state corruption, configuration issues. See `references/error-patterns.md` for detailed patterns and solutions. ## Integration After fixing: - Verify CI passes (types, tests, lint) - Stage atomic changes (fix + tests) - Suggest semantic commit message - Confirm with user before committing ## References For detailed guidance, see: - `references/root-cause-analysis.md` - Systematic analysis methods - `references/error-patterns.md` - Common error patterns and solutions - `references/debugging-tools.md` - Debugging tools and techniques
More Debugging skills
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
explore-code
lllllllama/rigorpilot-skills
Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant modules, adapt a backbone, add LoRA or adapter layers, replace a head, or stitch together meaningful low-risk migration ideas with rollback-aware records in `explore_outputs/`. Do not use for end-to-end exploration orchestration on top of `current_research`, trusted baseline reproduction, conservative debugging, environment setup, verified contribution claims, or default repository analysis.
safe-debug
lllllllama/rigorpilot-skills
Rigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training failure and wants conservative diagnosis before any patching, with debug fixes clearly separated from research contributions. Do not use for broad refactoring, speculative adaptation, automatic exploratory patching, or general repository familiarization.
