Conciseness

The body is mostly dense, useful checklists and commands, but there is real redundancy and padding: the mission is stated three times (intro "Your mission is to scan the project...", "## Your Mission", "## Scope"), the Invocation Examples section restates triggers already in the description, and the Build Timeline section walks through Xcode UI navigation (Report Navigator, Cmd+9, Assistant editor) that Claude already knows. It fits 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than 4, where over-explanation would be only minor.

Actionability

Guidance is largely executable: exact `xcproject settings`/`inspect` commands with all flags, exact setting names and expected values (e.g. `SWIFT_COMPILATION_MODE` = `singlefile` for Debug), a copy-paste timing-build snippet with exit-code handling, and a concrete ❌/✅ before/after fix. It stops short of 5 because `$SETTINGS_JSON` is passed to commands but never created or explained anywhere, and the `xcproject` fallback chain (plugin-root resolution, npx) is convoluted enough that a fresh run could stall.

Workflow Clarity

The Scan Process is a clearly sequenced 5-step workflow with specific commands per step, and validation checkpoints are present: fresh authorized capture vs. declared values, "do not infer missing settings as optimal defaults", pgrep inventory before running a build, exit-code-preserving failure handling, and "Always measure before and after". It does not reach 5 because there is no explicit feedback/re-validation loop after recommending fixes, and per-step output checks are implicit rather than a checklist.

Progressive Disclosure

The bundle contains no reference files at all (no references/, scripts/, assets/), and the ~215-line body inlines everything: a full build-settings catalog, phase-script red flags, timeline analysis, and output-format spec are all inline with only headers for navigation. The one cross-reference, `axiom-build (skills/build-performance.md)`, points to an external skill outside this bundle. This fits 'some structure but could be better organized; content that should be separate is inline' — good section structure keeps it above 2, but nothing is offloaded into one-level-deep reference files, so it cannot score 4.

Specificity

The description names the domain ("slow builds, build performance, or build time optimization") but contains no capability statement at all — no action verb, no mention of what the skill actually does (Xcode build auditing, settings analysis, script inspection). This names the domain with zero concrete actions, matching the score-2 anchor rather than score 1 (which requires entirely vague, abstract language), but it cannot reach 3 since not even one action is listed.

Completeness

The 'when' is explicit ("Use when the user mentions slow builds...") but the 'what' is entirely absent — the description never states what the skill does. This matches the score-2 anchor exactly ('only when is present without what', example: 'Use when working with documents') and is clearly below score 4/5, which require both a what and a when.

Trigger Term Quality

"slow builds" and "build performance" are natural phrases a user would say, but common variations are missing: no "compile times", no "builds take forever", no "speed up builds", and — critically for an Xcode-specific skill — no mention of Xcode, iOS, or macOS. This fits the anchor 'Some relevant keywords but missing common variations or synonyms' rather than 4, where keyword coverage would be good with only a few natural terms missing.

Distinctiveness Conflict Risk

The niche (build performance) is somewhat specific, but the description never mentions Xcode while the skill is exclusively Xcode-specific, so it would equally trigger for users needing Gradle, webpack, or Bazel build optimization. This overlaps with similar-sounding skills; not score 4 ("mostly distinct") because the platform qualifier is missing entirely.