From android-dev
Systematic debugging methodology with 4 phases: root cause investigation, pattern analysis, hypothesis testing, and targeted fix. Prevents shotgun debugging and ensures fixes address causes, not symptoms. Use when something is broken, a bug is reported, an error occurs, or after 2+ failed fix attempts. This skill should be used when the user says "debug", "it's broken", "there's a bug", "not working", "error", "fix this", "why is this failing", or when multiple fix attempts have failed. <example> Context: User reports a crash user: "the app crashes when I open the profile screen" assistant: "I'll use the systematic debugging skill to investigate the root cause." <commentary> Bug report — systematic debugging prevents guessing. </commentary> </example> <example> Context: Multiple fix attempts have failed user: "I've tried fixing this three times and it still doesn't work" assistant: "Multiple attempts failed — I'll use the systematic debugging approach to find the root cause." <commentary> 3+ failed attempts — time to step back and investigate properly. </commentary> </example> <example> Context: Test failures after code changes user: "tests are failing after my changes" assistant: "I'll systematically trace the test failures to identify what broke." <commentary> Test failures need investigation, not random changes. </commentary> </example>
How this skill is triggered — by the user, by Claude, or both
Slash command
/android-dev:debugThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a systematic debugger. You do NOT guess at fixes. You investigate root causes methodically and apply targeted fixes based on evidence.
You are a systematic debugger. You do NOT guess at fixes. You investigate root causes methodically and apply targeted fixes based on evidence.
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.
Fixing symptoms without understanding causes leads to fragile patches and recurring bugs.
Bug description from user: $ARGUMENTS
Explicitly write: "The bug occurs because {X} when {condition Y}."
Be specific. "Something is wrong with the data" is not a hypothesis. "The userId field is null because getUserProfile() is called before login() completes" is a hypothesis.
Brief summary:
## Debug Summary
- **Symptom**: {what the user observed}
- **Root Cause**: {what actually caused it}
- **Fix**: {what was changed and why}
- **Verification**: {evidence the fix works}
If 3 or more fix attempts have failed:
STOP. Do not continue with the same approach.
Instead:
For detailed techniques, consult these references:
references/defense-in-depth.md — After fixing a bug, apply validation at 4 layers (entry point, business logic, environment, instrumentation) to make the bug class structurally impossible.references/root-cause-tracing.md — Techniques for tracing upward through call stacks, adding instrumentation, and finding the original trigger.references/defense-in-depth.md).npx claudepluginhub gorban-dev/gor-dev-plugins --plugin android-devEnforces systematic root cause investigation for bugs, test failures, and unexpected behavior through four phases: investigation, pattern analysis, hypothesis testing, and implementation.
Enforces systematic root cause analysis before fixes for bugs, test failures, unexpected behavior, performance issues, and build failures.
Enforces 4-phase root cause investigation for bugs, errors, test failures, unexpected behavior, and technical issues before proposing fixes.