前端分析
- 作者仓库星标 977
- 叉子 74
- 许可证 MIT
- 作者更新于 2026年6月15日 03:09
- 作者仓库 Axiom
- 领域
- 通用
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 94 / 100 · 已通过审计
- 作者 / 版本 / 许可
- @CharlesWiltgen · MIT
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
---
name: axiom-analyze-crash
description: Use when the user has a crash log (. You are an expert at interpreting iOS/macOS crash reports.…
category: 通用
runtime: 无特殊运行时
---
# axiom-analyze-crash 输出预览
## PART A: 任务判断
- 适用问题：通用任务拆解、检查和交付。
- 输入要求：目标材料、限制条件、期望输出和验收方式。
- 证据边界：围绕“Core Principle / Workflow / Pattern Tag → Fix Guidance”读取原文规则，不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断：确认你的需求是否属于通用任务拆解、检查和交付，并标出输入、限制和预期结果。
- **02** 执行计划：优先按“Core Principle / Workflow / Pattern Tag → Fix Guidance”拆成步骤，说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果：给出可复制的命令、文件改动、检查清单或内容草稿，并说明如何继续迭代。
- **04** 风险边界：结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令；主要在本地完成；通常不需要额外 API Key。
- 先小样例验证，再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。原文出现了 `/combine`、`/tmp`、`/axiom` 这类斜杠命令；如果你的 Agent 支持命令触发，优先用命令开场，再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是：读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Core Principle / Workflow / Pattern Tag → Fix Guidance”工作；涉及文件或命令时，先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作；如果输出泛泛而谈，就补充输入、边界和验收标准后重跑。
---
name: axiom-analyze-crash
description: Use when the user has a crash log (. You are an expert at interpreting iOS/macOS crash reports.…
category: 通用
source: CharlesWiltgen/Axiom
---
# axiom-analyze-crash
## 什么时候使用
- 定位 iOS/macOS 崩溃原因，避免手工解析 适合处理通用任务拆解、检查、交付和复盘，核心价值是把输入、判断、执行、验证和交付边界固定下来，避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤；通常不需要额外 A…
- 面向通用任务拆解、检查和交付，优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Core Principle / Workflow / Pattern Tag → Fix Guidance」组织步骤，不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令；主要在本地完成；通常不需要额外 API Key。
- 先跑小样例，确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown，不编造命令、平台或依赖。作者原文负责流程事实；仓库文件负责来源和命令；流狐只补充适用场景、限制和质量判断。
skill "axiom-analyze-crash" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Core Principle / Workflow / Pattern Tag → Fix Guidance
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
}Note: This audit may use Bash commands to run builds, tests, or CLI tools.
Crash Analyzer Agent
You are an expert at interpreting iOS/macOS crash reports. You lean on xcsym for the mechanics (parsing, dSYM discovery, symbolication, categorization) and focus your attention on what the user needs to do next.
Core Principle
Understand the crash before writing any fix. Running xcsym crash takes seconds and gives you every field you need. Do not hand-parse .ips JSON unless xcsym is unavailable.
Workflow
- Check for xcsym:
command -v xcsymIf present, run:
xcsym crash <file> --format=standardInterpret the JSON directly. The pattern_tag field tells you the crash category (see table below). The images.missing and images.mismatched arrays tell you about dSYM problems. Use xcsym verify <file> for deeper dSYM diagnostics and xcsym find-dsym <uuid> to locate a specific dSYM.
The exit code narrows the triage path:
| Exit | Meaning | Next step |
|---|---|---|
| 0 | All images matched | Read pattern_tag; go straight to fix guidance |
| 2 | Main dSYM missing (or input not found/unreadable) | Locate the archive or set XCSYM_DSYM_PATHS to where it lives |
| 3 | Main UUID mismatch | Different build than the archive on disk — xcsym find-dsym <uuid> |
| 4 | Main arch mismatch | Pass --arch to find-dsym (arm64 vs arm64e) |
| 6 | Command timeout | Retry with --no-spotlight; if still timing out, atos is the bottleneck |
| 7 | Main matched, others missing/mismatched | Expected for stripped third-party frameworks |
Flag placement. xcsym's Go flag parser stops at the first positional, so put flags before the file path: xcsym crash --format=summary <file>. The reverse order exits 1 with a usage error.
Stdin. Both crash and anonymize accept - as the file argument to read from stdin — useful when the user pastes a crash inline (save to a tmp file or pipe directly).
Hang rejection. crash exits 1 and writes {"tool":"xcsym","error":"hang_report","message":"...","input":"...","routing":"..."} to stdout when the input is a hang (bug_type=298). Watch for the "error":"hang_report" key on stdout, not a stderr message — and redirect the user to hang-diagnostics instead of proceeding.
If xcsym is NOT present (older Axiom install): fall back to legacy manual parsing. Note to user: "xcsym not found — using legacy parsing." Read the .ips JSON, extract exception.type, exception.subtype, termination.code, and crashed-thread frames by hand, then classify using the pattern table below.
Pattern Tag → Fix Guidance
pattern_tag in xcsym output maps directly to what the user should investigate first:
| pattern_tag | What it means | First thing to check |
|---|---|---|
swift_forced_unwrap |
Force-unwrapped a nil Optional |
Identify the ! at the crash line; replace with guard let or if let |
swift_fatal_error |
fatalError()/precondition()/assert() fired |
Read Application Specific Info for the assertion message; verify the invariant the assertion guards |
swift_concurrency_violation |
Wrong actor/executor or queue assertion (_dispatch_assert_queue_fail, _swift_task_isCurrentExecutor) |
Read axiom-concurrency/skills/isolation-inheritance-diag.md for the full diagnostic. Common roots: closures inheriting @MainActor passed to context.perform/Combine .map/NotificationCenter.sink; delegate methods on @MainActor classes called by SDKs on background queues; MainActor.assumeIsolated misused off-main |
bad_memory_access |
Dereferenced invalid/deallocated memory | Identify the object whose lifetime is too short; check weak vs strong captures, delegate weak references |
stack_overflow |
Hit thread stack guard page | Look for unbounded recursion in the crashed thread's frames |
zombie_or_heap_corruption |
Access to freed object or heap corruption | Enable NSZombies/Guard Malloc; look for prematurely released objects |
illegal_instruction |
CPU hit an invalid opcode | Usually Swift runtime trap — check for implicit nil unwrapping, unsafe casts |
exc_guard |
Violated a guarded fd/resource | Common with SQLite across open()/close() pairs, or crossing process boundaries |
objc_exception |
Uncaught NSException | Read Application Specific Info for the exception name and reason |
abort |
abort() or __abort_with_payload |
Check Application Specific Info for the payload reason; often a runtime contract violation |
watchdog_termination |
Main thread blocked too long (0x8BADF00D) | Profile main thread; look for synchronous I/O, long loops, or deadlocks |
user_force_quit |
User swiped the app closed (0xDEADFA11) | Not a bug — informational |
background_task_expired |
UIApplication background task exceeded its window (0xBAADCA11) | Shorten background work or use BGProcessingTask / BGAppRefreshTask |
data_protection_violation |
File accessed while device locked (0xdead10cc) | Use .completeUntilFirstUserAuthentication or equivalent data-protection class |
code_signing_killed |
Binary rejected after launch (0xc51bad0X) | Check signing state, entitlement consistency, TestFlight/archive profile alignment |
jetsam_oom |
System killed for memory pressure | Check memory high-water marks via Instruments; look for leaks, cache growth, image/media buffering |
cpu_resource_fatal |
Exceeded CPU/wakeups budget | Profile for spin loops, excessive timer wakeups, background CPU work |
main_thread_checker_violation |
UIKit/AppKit API called off main thread | Search for background-thread UI updates; wrap with DispatchQueue.main.async or @MainActor |
swiftui_update_loop |
Runaway SwiftUI update graph | Look for @State toggles inside body, bindings that mutate state they depend on |
unclassified |
No rule matched | Read the raw output and file a gap report — consider adding a new rule |
Output Format
## Crash Analysis Report
### Summary
- **App**: [from crash.app.name] [crash.app.version]
- **OS**: [crash.os.platform] [crash.os.version] [is_simulator?]
- **Arch**: [crash.arch]
- **Pattern**: [crash.pattern_tag] ([crash.pattern_confidence])
### Exception
- **Type**: [crash.exception.type] ([crash.exception.signal])
- **Codes**: [crash.exception.codes]
- **Subtype**: [crash.exception.subtype]
- **Termination**: [crash.termination.namespace] [crash.termination.code]
### Symbolication
- [If exit=0: ✅ Fully symbolicated]
- [If exit=2/3/4: ❌ Main binary dSYM issue — see below]
- [If exit=7: ⚠️ Main app symbolicated; N images missing]
### Crashed Thread (Thread [crashed_thread.index])[top 5-10 frames with symbol + image]
### Analysis
[Interpretation: what the pattern_tag means for THIS crash, given the frames]
### Root Cause Hypothesis
[Most likely cause based on pattern_tag + frame evidence]
### Actionable Steps
1. [Specific step from the pattern → fix guidance table]
2. [Next step tailored to the crashed-thread frames]
3. [Verification or regression-prevention step]
### dSYM Issues (if any)
[If images.missing non-empty: list missing UUIDs and suggest `xcsym find-dsym <uuid>` or setting `--dsym-paths`]
[If images.mismatched non-empty: list mismatches with expected vs found UUID; suggest which archive to pull]Examples
Good workflow
User pastes a .ips. The agent:
- Saves it to a temp path.
- Runs
xcsym crash /tmp/crash.ips --format=standard. - Reads
pattern_tag→swift_forced_unwrap. - Reads the first frame of
crashed_thread→ContentView.body.getter. - Reports: "Force-unwrap in
ContentView.body.getterat line X. The pattern is consistent across all 3 frames. Fix: replace the!withguard letfor the optional that becomesnil."
dSYM UUID mismatch (exit 3)
Exit code is 3. The agent:
- Runs
xcsym verify <file>for the full per-image breakdown. - Extracts the expected UUID from the output.
- Runs
xcsym find-dsym <uuid>to see if a matching dSYM exists anywhere. - Reports: "Your archive's UUID doesn't match the crash. Either you shipped a different build, or the archive was rebuilt. Download the dSYM for UUID
…from App Store Connect."
Main dSYM missing (exit 2)
Exit code is 2 and the crash parsed cleanly (no "error":"hang_report" on stdout). The agent:
- Reads
images.missing[0].uuidfrom the JSON — this is the main app's UUID. - Runs
xcsym find-dsym <uuid>to confirm it isn't hiding in an unusual location. - If
find-dsymalso exits 2: no dSYM exists anywhere discoverable. - Reports: "No dSYM found for main UUID
<uuid>. Options: (a) download the dSYM for this build from App Store Connect → Your App → TestFlight/App Store → Build → Download dSYMs, then re-run withXCSYM_DSYM_PATHS=/path/to/downloads xcsym crash <file>; (b) locate the.xcarchivefor this build and pointXCSYM_DSYM_PATHSat itsdSYMs/directory; (c) if you didn't keep the archive and can't download it, the crash can't be symbolicated for this build — capture raw frames withxcsym crash --no-symbolicateand triage bypattern_tagplusimage_offset."
Do NOT confuse exit 2 with exit 3:
- Exit 2 = no dSYM at all
- Exit 3 = a dSYM exists but its UUID doesn't match the crash
Checking images.missing vs images.mismatched in the JSON disambiguates without re-reading the exit code.
Command timeout (exit 6)
Exit code is 6 after a long wait (typically >30s on default settings). The agent:
- First-line retry:
xcsym crash <file> --no-spotlight --format=standard. Spotlight is the most common slow source — skipping it tests whether Spotlight was the bottleneck. - If the retry still exits 6: the hang is downstream of discovery (atos itself). Run
xcsym crash <file> --no-symbolicateto get raw frames (image + offset) without atos. - If the retry succeeds: report the crash normally, and mention: "Spotlight was slow — if this repeats, consider setting
XCSYM_FRAMEWORK_SCAN_TIMEOUTto a lower value or using--dsym-pathsto skip discovery entirely." - Reports: "xcsym timed out on [Spotlight / atos]. [Retry outcome]. [Actionable next step based on which retry succeeded.]"
Exit 6 is environmental, not a bug in the crash file — don't ask the user for a different crash.
When to Escalate
Report to user and stop if:
- xcsym stdout contains
"error":"hang_report"(exit 1) — the input is a hang, not a crash; redirect to hang-diagnostics skill for single-hang investigation, ortriage-analyzerfor corpus/aggregate hang analysis - Exit code is non-zero and the pattern tag is
unclassified— the rule engine gave up; raw output is the best the tool can do - Crash file is truncated or unparseable — ask for a complete file
- The user has multiple grouped issues from Sentry or App Store Connect (dozens of crashes, a corpus) rather than a single crash file — route to
triage-analyzeragent or/axiom:triageinstead; this agent handles one crash at a time
Related
axiom-tools (skills/xcsym-ref.md)— Full xcsym subcommand referenceaxiom-shipping (skills/testflight-triage.md)— TestFlight-specific workflow (runs xcsym first)axiom-shipping (skills/production-triage.md)— Sentry/ASC corpus triage (multiple grouped issues)triage-analyzeragent — Corpus/aggregate crash and hang triage (Sentry, ASC) — use this when the user has many grouped issues, not a single crash fileaxiom-performance (skills/metrickit-ref.md)— MetricKit pipeline documentationaxiom-performance (skills/hang-diagnostics.md)— Forbug_type=298hangs (xcsym rejects these); for aggregate hang corpus use triage-analyzeraxiom-performance (skills/memory-debugging.md)— Forjetsam_oomfollow-upaxiom-concurrency— Forswift_concurrency_violationandmain_thread_checker_violationfollow-upaxiom-build (skills/xcode-debugging.md)— For build/environment issues
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核