triage

name	triage
description	Triage a Bugsnag production issue — either the top open issue or a specific issue by URL/ID. Investigate with evidence from stack traces / logs / breadcrumbs, propose a fix direction, route through domain experts, and write a lean review brief.
allowed-tools	["Bash","Read","Glob","Grep","Write","Edit","Agent","WebFetch","Skill"]

Triage: daily Bugsnag issue investigation

You are a senior Android engineer performing daily Bugsnag triage for the Flipcash Android app. Follow the steps below exactly.

Step 1 — Fetch the issue

If the user provided a Bugsnag URL or error ID, pass it to the helper script:

# Specific issue by URL
bash .claude/skills/triage/scripts/bugsnag-top.sh --url "https://app.bugsnag.com/org/project/errors/abc123"

# Specific issue by error ID
bash .claude/skills/triage/scripts/bugsnag-top.sh --error-id abc123

Otherwise, fetch the top open issue automatically:

bash .claude/skills/triage/scripts/bugsnag-top.sh

The script emits a single JSON object with:

Field	Description
error_id	Bugsnag error group ID
error_url	Deep link into the Bugsnag dashboard
event_url	REST API URL for the latest event
title	Error class + message
severity	error / warning / info
events	Total occurrences
users	Unique affected users
first_seen	ISO-8601 timestamp
release	app_version from the latest event

If the script exits non-zero, stop and report the error to the user.

Step 2 — Pull event detail

Fetch event_url (include header Authorization: token $BUGSNAG_TOKEN). Source .env from the repo root if the variable is not already set.

Parse the response using the event shape documented in .claude/skills/triage/references/event-shape.md.

Extract four evidence sources:

1. Stack trace — exceptions[0].stacktrace (frames with file, method, lineNumber, inProject)
2. Exception info — exceptions[0].errorClass + exceptions[0].message
3. App logs — metaData["App Logs"]["app_log"] (single string, last ~64 KB of log output)
4. Breadcrumbs — breadcrumbs[] (timestamped UI / state / network events)

Step 3 — Map stack frames to source

Android stack frames use Java/Kotlin package-qualified class names (e.g. com.flipcash.features.cash.CashViewModel). To locate the source file:

1. Convert the class name to a path fragment: replace . with / and append .kt (try .java as a fallback).
2. Use Glob to find the file in the repo (e.g. **/**/CashViewModel.kt).
3. Read the relevant lines (lineNumber from the frame +/- 30 lines of context).

Only map frames where inProject is true.

3a. Deobfuscate R8-obfuscated stacks

If the stack trace contains obfuscated class/method names (short lowercase names like ag3, b0, x2.a, or SourceFile instead of real filenames), Bugsnag failed to apply the R8 mapping. Deobfuscate manually:

1. Identify the versionCode from the event's app.versionCode field. If only versionName is available, check .well-known/release-manifest.json for the corresponding versionCode.

2. Download the R8 mapping using the r8-mapping skill:

   bash .claude/skills/r8-mapping/scripts/r8-mapping.sh <versionCode>
   

   This returns JSON with mapping_path pointing to the local mapping file.

3. Look up obfuscated classes:

   grep " -> <obfuscated_class>:" <mapping_path>
   

   Multiple results indicate R8 class merging — use stack trace line numbers to disambiguate (each class section contains line-number ranges for methods).

4. Look up methods within a class section:

   grep -A 200 "^com.original.ClassName -> <obfuscated>:" <mapping_path> | head -200
   

   Match the stack frame's line number against obfuscated_line_start:obfuscated_line_end to find the original method and source line.

5. Replace obfuscated frames with deobfuscated ones before proceeding to Step 4.

If the r8-mapping script needs a GitHub Actions run ID instead:

bash .claude/skills/build-lookup/scripts/build-lookup.sh <versionCode>

to find the run, then pass --run-id <id> to the r8-mapping script.

Step 4 — Build the evidence timeline

4a. Version check

Read .well-known/release-manifest.json to get the current production and internal release versions:

{
  "tracks": {
    "production": { "versionCode": 3508, "versionName": "2026.5.2" },
    "internal":   { "versionCode": 3508, "versionName": "2026.5.2" }
  }
}

Compare the event's app.version against tracks.production.versionName to determine if the crash still affects the latest release.

4b. Assemble evidence

Collect:

• The in-project stack frames mapped to source (file:line + code snippet)
• The exception class and message
• Relevant log lines (grep the app_log string for keywords from the exception)
• The last 10-20 breadcrumbs before the crash
• app.version, device.manufacturer, device.model, os.version

Step 5 — Investigate root cause

Using the evidence from Step 4:

1. Read the source files identified in the stack trace.
2. Follow the call chain — read callers and callees within 2 hops.
3. Check for known patterns: null-safety violations, lifecycle issues, threading bugs, uncaught coroutine exceptions, missing error handling.
4. Form a hypothesis and verify it against the logs and breadcrumbs.

Step 6 — Propose a fix direction

Write a concrete fix direction (NOT a full implementation):

• Which file(s) to change and roughly where (.kt:NN)
• What the fix involves (e.g. "add null check before accessing X", "move coroutine launch to lifecycleScope", "catch Y in Z")
• Why this addresses the root cause
• Any risks or side effects

Step 7 — Route through domain experts

Based on the evidence, tag relevant experts by adding their labels to the brief. An issue may match multiple experts.

Expert	Trigger
compose	Touches files with @Composable, Modifier, remember, LaunchedEffect, or under ui/, features/*/ui/
kotlin-coroutines	Stack contains CoroutineScope, Dispatchers, suspend, launch, async, withContext, Job, SupervisorJob
android-tdd	Proposed fix direction adds or modifies test files
kotlin-flows	Stack or fix involves Flow, StateFlow, SharedFlow, collect, stateIn

Step 8 — Write the review brief

Use the template in .claude/skills/triage/references/brief-template.md.

Save the brief to .claude/plans/triage-<error_id>.md.

Keep the brief under 300 words (excluding code snippets and the evidence appendix).

Step 9 — Next steps

If the fix direction is clear and well-scoped, offer to draft an implementation plan using superpowers:writing-plans.

If the root cause is ambiguous, suggest specific debugging steps (add logging, reproduce locally, check related Bugsnag issues).