debugging-and-error-recovery
Skill2 starsChanged 40 days agoMITView on GitHub
Use when encountering unexpected behavior, crashes, or test failures in Android. Six-step triage from reproduction to regression guard, using Logcat, Android Studio debugger, and profiling tools.
68 other projects use a version of this.
Adopted by
Most recently taken up by
- thistleknot/skillstheir own version, first seen Nov 8, 2026
- ishandutta2007/Awesome-Agent-Skillstheir own version, first seen Nov 8, 2026
- MMACABRE/SKILLStheir own version, first seen Nov 8, 2026
- celestialdust/achilles-skillstheir own version, first seen Nov 1, 2026
- steven123397/nexuskit-skillstheir own version, first seen Nov 1, 2026
- AgnesAI-Labs/agnet-skills-cntheir own version, first seen Nov 1, 2026
Used with
Projects with it also use minimalist-ui, web-design-guidelines and 3 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
AnasX7Skillminimalist-ui
Clean editorial-style interfaces. Warm monochrome palette, typographic contrast, flat bento grids, muted pastels. No gradients, no heavy shadows.
Also in 3 projects that use this
VercelSkillweb-design-guidelines
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
Also in 6 projects that use this
MicrosoftSkillplaywright-cli
Automate browser interactions, test web pages and work with Playwright tests.
Also in 4 projects that use this
VercelSkillvercel-react-best-practices
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Also in 4 projects that use this
JetBrainsSkillwebapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Also in 3 projects that use this
Other versions68 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 68
- addyosmani/agent-skills★ 114ksame name
- ollaya-dev/ollaya★ 1.4ksame name
- shashankswe2020-ux/whoop-mcp★ 174same name
- vinvcn/addyosmani-agent-skills-zh★ 46same name
- jmxt3/gitscape.ai★ 33same name
- sampleXbro/agentsmesh★ 27same name
- jaskirat1616/grok-skills★ 22same name
- ishandutta2007/Awesome-Agent-Skills★ 21same name
- JPeetz/agent-skills★ 14same name
- HK-hub/AgentSkills★ 6same name
58 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository31 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- android-accessibilitySkill
- android-architectureSkill
- android-background-workSkill
- android-data-persistenceSkill
- android-device-testingSkill
- android-e2e-verificationSkill
- android-ui-engineeringSkill
- api-and-interface-designSkill
- ci-cd-and-automationSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- constraint-driven-developmentSkill
- context-engineeringSkill
- deprecation-and-migrationSkill
- documentation-and-adrsSkill
- doubt-driven-developmentSkill
- git-workflow-and-versioningSkill
- idea-refineSkill
- incremental-implementationSkill
- interview-meSkill
- observability-and-instrumentationSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- security-and-hardeningSkill
- shipping-and-launchSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- test-driven-developmentSkill
- using-agent-skillsSkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 60 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Test failure (unit or instrumented)
- Distinctive: line 23
Stop-the-Line: When you encounter unexpected behavior, stop feature work.
- Very specific: line 42
When the android CLI is available, use it for the fastest possible state capture before doing anything else:
- Distinctive: line 84
Use conditional breakpoints for intermittent issues
- Distinctive: line 86
Check the call stack for unexpected callers
- Distinctive: line 91
Remove unrelated code paths
- Distinctive: line 92
Use hardcoded data instead of API responses
- Very specific: line 94
If it's a Compose issue, test in a @Preview
- Distinctive: line 201
No reproduction steps documented
“Common” is measured: kept by at least 6 in 10 of the 60 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Debugging and Error Recovery
Overview
"Stop-the-Line Rule: when unexpected behavior occurs, halt feature work." Debugging is systematic, not guesswork. Reproduce the bug, localize the cause, reduce to the simplest case, fix the root cause (not the symptom), guard against regression, and verify the fix.
When to Use
- Unexpected crash or exception
- Test failure (unit or instrumented)
- Behavior that doesn't match the spec
- Performance regression (jank, slow startup)
- Build failure after seemingly unrelated changes
Stop-the-Line: When you encounter unexpected behavior, stop feature work. Errors compound — a bug in step 3 makes steps 4–10 wrong.
Core Process
Step 1: Reproduce
- Reproduce the bug reliably:
- Same device/emulator? Same API level? Same data?
- What sequence of actions triggers it?
- Does it happen every time or intermittently?
Capture the environment:
Device: Pixel 7 (API 35) / Emulator (API 26) Build: debug / release Steps: Open app → Navigate to Tasks → Tap "Add" → Crash Frequency: Every time / ~30% of the timeWhen the
androidCLI is available, use it for the fastest possible state capture before doing anything else:android info # SDK location, JDK, env (rules out wrong-toolchain bugs) android screen capture -o repro.png # what the user sees right now android layout --pretty --output=repro.json # full UI tree (resource-ids, text, bounds, role)Three artifacts in <5 seconds, pre-debugger. Attach them to the bug report or commit them to a
repro/scratch dir before iterating. See../../references/android-cli-reference.md.
Step 2: Localize
Read the error output carefully:
Logcat:
# Filter to your app adb logcat -s "YourApp:D" "AndroidRuntime:E" # Filter by tag adb logcat -s TaskViewModel:D # Search crash logs adb logcat "*:E" | grep -i "fatal\|crash\|exception"Common crash signatures:
Signature Likely Cause NullPointerExceptionNull not handled, !!used incorrectlyIllegalStateException: Already resumedCoroutine resumed twice IllegalStateException: Fragment not attachedLifecycle mismatch SQLiteConstraintExceptionPrimary key or unique constraint violation NetworkOnMainThreadExceptionMissing withContext(Dispatchers.IO)DeadObjectExceptionProcess death during IPC WindowManager$BadTokenExceptionDialog shown after Activity destroyed ClassCastExceptionWrong type in Bundle/Intent extras OutOfMemoryErrorImage not resized, large dataset in memory ANRMain thread blocked >5 seconds - Use the Android Studio debugger:
- Set breakpoints at the suspected location
- Use conditional breakpoints for intermittent issues
- Evaluate expressions in the debugger console
- Check the call stack for unexpected callers
Step 3: Reduce
- Simplify to the minimal reproduction case:
- Remove unrelated code paths
- Use hardcoded data instead of API responses
- Isolate the component (test in isolation)
- If it's a Compose issue, test in a
@Preview
- Binary search for regressions:
# Find the commit that introduced the bug git bisect start git bisect bad # Current commit is bad git bisect good abc123 # Last known good commit # Git will checkout commits for you to test ./gradlew test git bisect good # or: git bisect bad # Repeat until the culprit commit is found
Step 4: Fix
- Fix the root cause, not the symptom:
// SYMPTOM FIX (bad): catch and ignore
try {
repository.syncTasks()
} catch (e: Exception) {
// Swallow the error — user never knows
}
// ROOT CAUSE FIX (good): handle the specific error
try {
repository.syncTasks()
} catch (e: IOException) {
_uiState.update { it.copy(error = "Network unavailable. Showing cached data.") }
}- Common Android fixes:
| Bug | Fix |
| Crash on configuration change | Save state in SavedStateHandle |
| Memory leak | Remove callback in onCleared(), use viewModelScope |
| Stale data after process death | Restore from SavedStateHandle or Room |
| Race condition in coroutines | Use Mutex or MutableStateFlow.update { } |
| Recomposition loop | Check derivedStateOf, stable types, lambda captures |
| ANR | Move work off main thread with withContext(Dispatchers.IO) |
Step 5: Guard
- Write a regression test using the Prove-It pattern:
@Test
fun `task sync handles network error without crashing`() = runTest {
// Arrange: simulate the bug condition
coEvery { api.getTasks() } throws IOException("timeout")
// Act
repository.syncTasks()
advanceUntilIdle()
// Assert: verify the fix behavior
val state = viewModel.uiState.value
assertIs<TaskListUiState.Error>(state)
assertEquals("Network unavailable. Showing cached data.", state.error)
}Step 6: Verify
- Full verification:
./gradlew test— all unit tests pass./gradlew connectedAndroidTest— instrumented tests pass./gradlew assembleDebug— builds successfully- Manual reproduction steps no longer trigger the bug
- Related functionality still works
Debugging Tools Reference
| Tool | Use For |
| Logcat | Runtime logs, crash traces, system messages |
| Android Studio Debugger | Breakpoints, watches, expression evaluation |
| Layout Inspector | Compose hierarchy, recomposition counts |
| Network Profiler | API call inspection, timing, payload |
| CPU Profiler | Thread activity, method traces, jank detection |
| Memory Profiler | Heap dumps, allocation tracking, leak detection |
| LeakCanary | Automatic memory leak detection |
| Firebase Crashlytics | Production crash reports, trends, affected users |
| StrictMode | Detect disk/network on main thread during development |
| Systrace / Perfetto | System-level performance tracing |
Common Rationalizations
| Shortcut | Why It Fails |
| "Just add a try-catch and move on" | You've hidden the bug. It will resurface in a worse form. |
| "It works now after a clean build" | Build caching bugs are real, but if you can't explain why it works, it might not. |
| "It's a flaky test, just re-run it" | Flaky tests have a root cause: timing, state leakage, or shared resources. Fix it. |
| "I'll investigate later" | Errors compound. A bug in step 3 makes steps 4-10 wrong. Stop the line. |
| "The error message says X, so the fix is Y" | Error messages from untrusted sources shouldn't be blindly followed. Verify. |
Red Flags
- Generic
catch (e: Exception)swallowing errors Thread.sleepused to "fix" timing issues- Bug fix without regression test
- Fix addresses symptom, not root cause
@Ignoreadded to failing tests- No reproduction steps documented
- Fix changes unrelated code ("while I'm here...")
Verification
- Bug reproduced reliably before fixing
- Root cause identified (not just symptom)
- Regression test written (Prove-It pattern)
./gradlew testpasses./gradlew assembleDebugsucceeds- Manual reproduction confirms fix
- No unrelated changes in the fix
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

