Conciseness

The body is dense with directives and assumes Claude's competence (no explanation of what Xcode, SwiftPM, or Info.plist are), delegating full script bodies to the reference. It is not a 5 because the kill-build-run contract and the raw-executable-launch warning ('Do not recommend direct SwiftPM executable launch...' / 'Do not launch a SwiftUI/AppKit SwiftPM GUI app as a raw executable...') are repeated across Quick Start, Workflow step 3, Guardrails, and the reference, and the Quick Start flag list duplicates the Preferred Commands list.

Actionability

Concrete executable commands appear throughout: 'find . -name '*.xcworkspace' -o ...', 'xcodebuild -list -workspace <workspace>', './script/build_and_run.sh --telemetry', exact Info.plist keys, 'pgrep -x <AppName>', and 'NSApp.setActivationPolicy(.regular)'. The full copy-paste-ready scripts live one level deep in references/build-script.md, covering both common cases (SwiftPM CLI and GUI). This matches anchor 5; anchor 4 would imply missing key details that are instead all present across body plus reference.

Workflow Clarity

The 7-step workflow is clearly sequenced — discover shape, resolve target, create script, build/run, classify failures, debug, use MCP — with concrete checkpoints like '--verify' to 'confirm the process exists with pgrep -x <AppName>' and failure classification in step 5. It stops short of anchor 5 because the validate-fix-retry feedback loop is implicit rather than explicit: there is no 'fix and re-run' step after classifying a blocker, so a validation gap remains.

Progressive Disclosure

Structure is good: a one-level-deep, clearly signaled reference ('references/build-script.md: canonical script/build_and_run.sh shapes...') that is explicitly designated the canonical source, and it is a real file in the bundle. Not a 5 because the body still inlines script-shape detail that also lives in the reference (plist keys, open -n launch details, activation-policy advice appear in both), leaving minor duplication that could be consolidated.

Specificity

The description enumerates multiple concrete, comprehensive actions — 'Build, run, and debug local macOS apps and desktop executables' plus 'diagnose compiler or linker failures, inspect startup problems, or debug desktop-only runtime issues'. This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage'; it falls short of nothing below it since anchor 4 tolerates coverage gaps this description does not have.

Completeness

It explicitly answers both parts: 'Build, run, and debug local macOS apps and desktop executables using shell-first Xcode and Swift workflows' (what) and 'Use when asked to build a Mac app, launch it, diagnose compiler or linker failures...' (when, with concrete trigger phrases). This matches anchor 5 exactly; anchor 4 would require a weaker or less explicit 'when' clause.

Trigger Term Quality

Natural phrases users would actually say are present: 'build a Mac app', 'launch it', 'diagnose compiler or linker failures', 'inspect startup problems', 'debug desktop-only runtime issues'. Coverage is good but misses common synonyms users say ('run my app', 'Xcode project', 'SwiftUI', 'crash', '.app'), so it fits anchor 4 rather than the comprehensive synonym coverage of anchor 5.

Distinctiveness Conflict Risk

The niche is clear — 'local macOS apps and desktop executables' and 'desktop-only runtime issues' — with triggers mostly distinct from iOS/simulator or general-language build skills. However, 'diagnose compiler or linker failures' is generic enough to invite overlap with non-macOS build skills, matching 'mostly distinct; minor overlap risk' (anchor 4) rather than the minimal-conflict anchor 5.