Conciseness

The body is dense and earns its tokens — exit-code and pattern tables, exact commands, no explanation of what a crash file is, assuming Claude's competence throughout. It falls short of anchor 5 due to repetition: the exit 2 vs exit 3 distinction is stated three times (table rows, "Do NOT confuse exit 2 with exit 3", and "Checking images.missing vs images.mismatched ... disambiguates"), and the five invocation examples could be trimmed to two. Well above anchor 3, which requires unnecessary conceptual explanation that is absent here.

Actionability

Fully executable, copy-paste-ready guidance: `xcsym crash <file> --format=standard`, `command -v xcsym`, `xcsym verify <file>`, `xcsym find-dsym <uuid>`, `--arch`, `--no-spotlight`, `--no-symbolicate`, and `XCSYM_DSYM_PATHS=... xcsym crash <file>`, plus a per-exit-code next-step table and worked examples covering the common cases (happy path, exit 3, exit 2, exit 6 retry ladder). Matches anchor 5 exactly.

Workflow Clarity

Clear sequence (check for xcsym → run crash → interpret exit code → pattern_tag → fix guidance) with an explicit validation checkpoint in the exit-code table, a full fallback chain (binary → `<plugin-root>/tools/xcsym` → `axiom_xcsym_crash` MCP tool → legacy manual parsing), error-recovery loops (exit 6: retry `--no-spotlight`, then `--no-symbolicate`), and a defined escalation section. This is the anchor-5 feedback-loop structure; anchor 4 would leave validation gaps, and there are none.

Progressive Disclosure

Well-organized sections with clear headers and a Related section pointing one level deep to external skills (`axiom-tools (skills/xcsym-ref.md)`, `axiom-performance (skills/hang-diagnostics.md)`, etc.). Not a 5 because this skill ships no bundle files of its own while inlining ~200 lines of reference-grade material (the 20-row pattern→fix table, the full output template, five invocation examples) that could partly live in a references/ file; not a 3 because what is inline is clearly sectioned and the external pointers are explicit.

Specificity

The description names the domain precisely with concrete input formats — "crash log (.ips, MetricKit JSON, legacy .crash text, .xccrashpoint bundle, or pasted text)" — but the only action stated is the generic "needs analysis"; no concrete actions like parse, symbolicate, categorize, or suggest fixes appear. This sits between anchor 2 ("Processes PDF files" — no comparable format detail) and anchor 4 (multiple specific actions listed), matching anchor 3's single-action coverage.

Completeness

Both parts are present: "Use when the user has a crash log (...) that needs analysis" gives an explicit, specific trigger clause, and the what — analyzing crash logs — is stated. Not a 5 because the what-side is thin ("analysis" names no concrete operations like parsing, symbolication, or fix guidance, unlike the anchor-5 example listing three concrete actions); not a 3 because the when-clause is explicit rather than weakly implied.

Trigger Term Quality

Good keyword coverage including file extensions (".ips", ".crash", ".xccrashpoint") and format names ("MetricKit JSON", "pasted text"), which users genuinely paste into requests. It falls short of anchor 5 because the very common synonym "crash report" (Apple's own term) and phrases like "symbolicate" or "stack trace" are missing, but it is well above anchor 3's bare "Works with PDF files" level.

Distinctiveness Conflict Risk

"crash log (.ips, MetricKit JSON, legacy .crash text, .xccrashpoint bundle, or pasted text)" carves out a clear niche with distinct, format-specific triggers; virtually no other skill would fire on these inputs. Minimal conflict risk, matching anchor 5.