Root cause investigation methodology for bugs and failures. Use when encountering test failures, unexpected behavior, or errors during research or implement phases. Find the cause before attempting fixes.
/plugin marketplace add bostonaholic/rpikit/plugin install rpikit@rpikitThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Find the root cause before attempting fixes. Symptom fixes are failure.
Debugging without methodology wastes time and creates new bugs. Random fixes address symptoms, not causes. This skill enforces systematic investigation to find root causes before any fix is attempted.
ALWAYS find root cause before attempting fixes.
Quick patches mask underlying issues. If you're trying fixes without understanding why they might work, you're guessing - stop and investigate.
Complete each phase in order. Do not skip to implementation.
Understand what's happening before theorizing why.
Read the error carefully
Reproduce consistently
Review recent changes
Gather diagnostic evidence
Trace backwards
Compare against working code.
Find similar working code
Compare against references
Identify the difference
Understand dependencies
Scientific method for debugging.
Form a single hypothesis
Design a test
Make minimal changes
Observe results
Iterate or proceed
Fix only after understanding.
Write a failing test
Implement single fix
Verify the fix
Check for related issues
| Thought | Reality |
|---|---|
| "Let me try this quick fix" | You don't understand the cause |
| "I'll just restart the service" | Masking the symptom |
| "Maybe if I add a null check here" | Guessing, not debugging |
| "Let me try a few things" | Random changes waste time |
| "This usually fixes it" | Past fixes don't explain current bugs |
| "I don't have time to investigate" | You don't have time NOT to |
When investigating an issue:
When a step fails verification:
If you've attempted three or more fixes and the problem persists:
Stop fixing. Question the architecture.
Use AskUserQuestion to discuss architectural concerns before continuing.
Add temporary logging:
- Entry/exit of functions
- Variable values at key points
- Timestamps for timing issues
- Request/response payloads
When did it break?
- git bisect to find breaking commit
- Binary search through code changes
- Narrow down to specific change
Simplify to reproduce:
- Remove unrelated code
- Use minimal test case
- Eliminate variables
What's different?
- Working vs broken environment
- Working vs broken input
- Working vs broken configuration
Wrong: Try random changes hoping one works Right: Form hypothesis, test it, iterate
Wrong: Apply fix, hope it works, move on Right: Verify fix addresses root cause
Wrong: Remove code until error goes away Right: Understand why code causes error
Wrong: Find similar fix online, apply blindly Right: Understand why the fix works for your case
Wrong: "I think I know the fix, let me just try it" Right: Complete investigation phases first
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.