Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
/plugin marketplace add mtthsnc/autonome/plugin install autonome@autonome-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
CREATION-LOG.mdcondition-based-waiting-example.tscondition-based-waiting.mddefense-in-depth.mdfind-polluter.shroot-cause-tracing.mdtest-academic.mdtest-pressure-1.mdtest-pressure-2.mdtest-pressure-3.mdRandom fixes waste time and create new bugs. Quick patches mask underlying issues.
Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
If you haven't completed Phase 1, you cannot propose fixes.
BEFORE attempting ANY fix:
Read Error Messages Carefully
Reproduce Consistently
Check Recent Changes
Gather Evidence in Multi-Component Systems
For each component boundary:
Run once to gather evidence showing WHERE it breaks THEN analyze evidence to identify failing component
Trace Data Flow
Find Working Examples
Compare Against References
Identify Differences
Form Single Hypothesis
Test Minimally
Verify Before Continuing
Create Failing Test Case
Implement Single Fix
Verify Fix
If Fix Doesn't Work
If 3+ Fixes Failed: Question Architecture
Pattern indicating architectural problem:
STOP and question fundamentals:
Discuss before attempting more fixes.
If you catch yourself thinking:
ALL of these mean: STOP. Return to Phase 1.
If 3+ fixes failed: Question the architecture.
| Excuse | Reality |
|---|---|
| "Issue is simple, don't need process" | Simple issues have root causes too. |
| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check. |
| "Just try this first, then investigate" | First fix sets the pattern. Do it right from start. |
| "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. |
| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. |
Available in this directory:
Related skills:
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.