菜单
Set up crash instrumentation with actionable context. Use when configuring crash capture, error boundaries, or breadcrumb strategies.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | crash-instrumentation |
| description | Set up crash instrumentation with actionable context. Use when configuring crash capture, error boundaries, or breadcrumb strategies. |
| triggers | ["breadcrumb strategy","capture crashes","crash context","crash reporting","debug crashes","error boundaries"] |
| priority | 1 |
Capture crashes with the context needed to debug them.
A crash report without context is useless. Every crash should include:
| Context | Why | Example |
|---|---|---|
screen | Where it happened | "CheckoutScreen" |
job_name | What user was doing | "checkout" |
job_step | Where in the flow | "payment" |
breadcrumbs | What led here | Last 20 user actions |
app_version | Release correlation | "1.2.3" |
user_segment | Who's affected | "premium", "trial" |
Breadcrumbs are the trail leading to a crash. Capture:
| Category | What to Log | Example |
|---|---|---|
navigation | Screen transitions | "HomeScreen → CartScreen" |
user | Taps, inputs, gestures | "Tapped checkout button" |
network | API calls (not payloads) | "POST /api/orders started" |
state | Key state changes | "Cart updated: 3 items" |
error | Non-fatal errors | "Retry #2 for payment" |
Limit: Keep last 20-50 breadcrumbs. More is noise.
Catch errors before they crash the app:
// iOS - capture context before crash
func captureError(_ error: Error, screen: String, job: String?) {
Observability.captureError(error, context: [
"screen": screen,
"job_name": job ?? "unknown",
"session_duration": sessionDuration(),
"memory_pressure": memoryPressure()
])
}
// Android - uncaught exception handler
Thread.setDefaultUncaughtExceptionHandler { thread, throwable ->
Observability.captureError(throwable, mapOf(
"thread" to thread.name,
"screen" to currentScreen,
"job_name" to currentJob
))
previousHandler?.uncaughtException(thread, throwable)
}
| Don't | Why |
|---|---|
| Full stack traces in breadcrumbs | Redundant, SDK captures this |
| User input text | PII risk |
| Full request/response bodies | Size limits, PII |
| Entire app state | Unbounded, noise |
| Platform | Type | Instrumentation |
|---|---|---|
| iOS | EXC_BAD_ACCESS | Breadcrumbs, memory context |
| iOS | SIGKILL (watchdog) | Background task tracking |
| Android | ANR | Main thread breadcrumbs |
| Android | OutOfMemoryError | Memory tracking |
| React Native | JS exceptions | Error boundaries |
See references/crash-reporting.md for:
See skills/symbolication-setup for readable stack traces.
Configure crash symbolication for readable stack traces. Use when setting up dSYMs (iOS), ProGuard/R8 mappings (Android), or source maps (React Native).
Plan what to measure in mobile apps. Use when starting observability, prioritizing instrumentation, or asking "what should I track?"
Measure time from user tap to action completion. Use when tracking button response times, form submissions, add-to-cart, or any tap-triggered operation.
Measure time from navigation tap to screen fully loaded and interactive. Use when tracking screen transitions, deep links, or tab switches.
Instrument API requests with spans and distributed tracing. Use when tracking request latency, correlating client-backend traces, or debugging API issues.
Set up session replay for visual debugging. Use when implementing screen recording, replay features, or visual debugging tools.