Fix Crash

Skill: Root-Cause, Reproduce, and Fix a Production Crash

Takes one Crashlytics issue (or the GitHub issue tracking it) from symptom to a verified fix, without breaking users whose stored data was written by an older release.

Finding which crashes to work on is a different skill: triage-crashes. This one fixes a single known crash. Read triage-crashes for how the Crashlytics MCP bridge works — this skill uses the same scripts/crashlytics.js and the same appId.

Step 1 — Resolve the crash and its GitHub issue

You may be given a Crashlytics issue id, a console URL, a GitHub issue number, or a description. Get to a (crashlyticsIssueId, githubIssueNumber) pair, where either may be absent:

The Crashlytics id is the join key in both directions — issues filed by triage-crashes carry it in their body and a note pointing back. If you find a GitHub issue with no Crashlytics note, add the note now with crashlytics_create_note.

If no GitHub issue exists, file one with create_issue (label bug) using the triage-crashes body format before starting work, so the fix has something to close.

Step 2 — Pull everything the platform knows

[
  { "name": "crashlytics_get_issue", "arguments": { "appId": "1:636588470688:android:c27a676c8deb5eb0", "issueId": "<id>" } },
  { "name": "crashlytics_list_events", "arguments": { "appId": "...", "pageSize": 5, "filter": { "issueId": "<id>" } } },
  { "name": "crashlytics_get_report", "arguments": { "appId": "...", "report": "topAndroidDevices", "pageSize": 10, "filter": { "issueId": "<id>" } } },
  { "name": "crashlytics_get_report", "arguments": { "appId": "...", "report": "topOperatingSystems", "pageSize": 10, "filter": { "issueId": "<id>" } } },
  { "name": "crashlytics_get_report", "arguments": { "appId": "...", "report": "topVersions", "pageSize": 10, "filter": { "issueId": "<id>" } } }
]

Read several events, not just one. One stack tells you where it broke; several tell you what the occurrences share. Look at each event's breadcrumbs, custom keys, and device state.

The distribution is evidence, and it usually names the root cause on its own:

firstSeenVersion plus git log <prev-tag>..<that-tag> is the fastest route to a regression's cause.

Step 3 — Root cause it in this repo

Find the deepest sk.styk.martin.apkanalyzer.* frame, map its package to a module (see AGENTS.md), read that module's AGENTS.md, then read the actual code. Then state the root cause as one sentence naming the specific condition — "ON CONFLICT upsert syntax requires SQLite 3.24, which is absent below API 30", not "a database error".

Do not start editing until you can state that sentence. If the evidence doesn't support one, say so and pull more events rather than guessing.

Watch for these, which this codebase has actually produced:

• A framework symbol that doesn't exist on older API levels (NoSuchMethodError, NoSuchFieldError) — the compile-time SDK has it, the runtime device doesn't.
• Raw SQL in a Room @Query using syntax newer than the device's bundled SQLite.
• A LazyColumn item key that isn't unique across the whole list.
• A SecurityException from a package the caller can't inspect on newer Android.

Step 4 — Reproduce before fixing

An unreproduced fix is a guess. Reproduce in the cheapest way that actually exercises the failure:

1. Match the environment. If the distribution points at an API level, start an emulator at that exact level — a fix verified only on your daily driver proves nothing about an API-29 crash. Use the run-app skill to build, install and launch, and navigate-app-adb to drive to the screen.
2. Reach the state. Breadcrumbs and custom keys on the event tell you what the user did. For a crash needing specific stored data, seed it via the app's own flows, or with adb shell against the app's database — never by adding production code that fabricates the state.
3. Confirm the same stack. adb logcat must show the same exception at the same frame. A different crash on the same screen is a different bug.

If it genuinely can't be reproduced locally (OEM-specific, a device you don't have), say so explicitly, and compensate: write the fix so the failing path is provably impossible (a version guard, a supported API) rather than probabilistically better, and prove the guard with the API level you can run.

Never add a debug hook, test-only flag, or logging to production code to force a repro. Remove any temporary scaffolding before finishing.

Step 5 — Fix it

Follow AGENTS.md and the module's own AGENTS.md. Beyond those:

• Fix the cause, not the symptom. A try/catch around a crash that leaves the feature silently broken is not a fix — AGENTS.md forbids hiding errors behind broad exception handling. Catching is only correct when the exception is genuinely expected and the app has a real answer for it.
• Prefer the platform-supported API over a version-guarded fork when one exists.
• If the same broken pattern appears elsewhere, fix every occurrence — grep for it. Shipping a fix for one of three identical DAOs means two more crash reports next release.