Conciseness

The body is dense with operational specifics and wastes almost nothing on concepts Claude already knows — every section carries non-obvious domain knowledge (pagination quirks, 'statsPeriod accepts only empty/24h/14d', frame reversal, '|sys:' fallback handling). Minor tightening possible: the single-crash/local-Organizer boundary is stated in full twice (Single-Crash Escape Hatch and Scope), and 'flag, never hide' is repeated across sections.

Actionability

Fully executable guidance throughout: exact endpoints with query parameters, token lookup order with a limit=1 scope probe, a copy-paste-ready 'xcsym triage' command with explicit flag-omission rule, exact TriageResult field semantics, and a complete report template including column order and sort rules. The common cases (Sentry pagination, missing TestFlight logs, malformed lines) are each covered with a specific handling rule.

Workflow Clarity

Six clearly numbered workflow steps with real checkpoints for a batch operation: the 401/403 token probe ('report that, don't proceed into a confusing partial failure'), mandatory Link-header pagination until exhausted, 'Announce any cap you impose', and errors[] surfacing for unclassifiable issues. It falls short of anchor 5 because there is no validate-then-fix feedback loop (e.g. what to do when a fetch page fails mid-pagination or when semantic merge is ambiguous), though validation is clearly present rather than missing so the batch cap at 3 does not apply.

Progressive Disclosure

Good structure with well-signaled, one-level-deep cross-skill references (axiom-shipping production-triage.md / testflight-triage.md, axiom-tools xcsym-ref.md, crash-analyzer, axiom-data, axiom-performance) collected in a Related section. No bundle files exist to verify beyond the listing. It is not anchor 5 because substantial reference-grade content (the three verbatim standing notes) is inlined rather than split out — a deliberate, explicitly justified trade-off (dangling-pointer risk plus the pre-deploy.ts byte-identity assertion), but an inlining nonetheless.

Specificity

The description names the domain concretely ('triage a CORPUS of production crashes/hangs from an aggregator (Sentry, App Store Connect)') but offers only the single action verb 'triage' — it does not list the concrete operations (fetch, classify, cluster, flag noise, rank, report) the body actually performs, matching the 'names domain and 1-2 concrete actions, but not comprehensive' anchor.

Completeness

The 'when' is excellent and explicit ('Use when the user wants to triage a CORPUS ... rather than a single crash file', including the negative trigger), but the 'what' is thin — 'triage' alone does not convey the output (ranked real-bug families, noise deprioritization). Not the 5 anchor because the what-side lacks concrete multi-action phrasing; clearly above anchor 3 since both what and when are present and the when carries concrete trigger phrases.

Trigger Term Quality

Strong natural terms — 'triage', 'production crashes/hangs', 'Sentry', 'App Store Connect', 'grouped, counted issues' — map well to what a user would say ('triage my Sentry crashes'). A few natural variants are absent (e.g. 'crash reports', '.ips', 'crash grouping'), so it is good-but-not-comprehensive coverage.

Distinctiveness Conflict Risk

Clear niche with built-in disambiguation: 'corpus from an aggregator (Sentry, App Store Connect) ... rather than a single crash file' explicitly separates this skill from single-crash analyzers and other skills. Minimal conflict risk.