Conciseness

There is no padding or explanation of concepts Claude already knows, but the dot-graph Decision Tree restates the Quick Reference table's routing almost row-for-row (~20 redundant lines), and "Cross-Suite Routes" and "Conflict Resolution" both explain the same axiom-macos vs axiom-swiftui boundary. This fits anchor 3 ("mostly efficient but could be tightened") better than anchor 4's "minor instances".

Actionability

Pointers are concrete and executable — "See `skills/windows.md`", "Launch `touch-auditor` agent or `/axiom:audit touch`", "`axiom_get_agent` returns it" — including a fallback path when agents can't launch. Not anchor 5: most table rows name only a destination file without stating the action to take there, and paths are relative to an unstated suite root.

Workflow Clarity

As a single-purpose routing skill, the one action (match task → follow reference) is made near-deterministic by the symptom table, decision tree, and explicit conflict-resolution rules for overlapping cases, with environment-specific fallbacks for agent launch. Minor residual ambiguity (e.g., the Apple Pay/Catalyst row vs ios-apps-on-mac) keeps it at anchor 4 rather than 5.

Progressive Disclosure

The body is a pure overview/index: all detail is deferred to one-level-deep, clearly signaled references organized by symptom, which is exemplary router structure. However, no bundle files are present — every referenced path ("skills/*.md", "axiom-payments/skills/apple-pay.md") resolves against the surrounding suite rather than this bundle, so navigation is not self-contained; this is anchor 4 (good structure, minor organization gaps) rather than 5.

Specificity

Phrases like "windows, menus, sandboxing, distribution, AppKit bridging or modernization (control events, state restoration, concentric corners)" name concrete, well-scoped topic areas, but no action verbs are stated anywhere — it is a trigger list, not a capability list. This matches anchor 3 (clear domain, concrete scope) better than anchor 4 ("lists several specific actions") because zero actions are explicit, and better than anchor 2 because the enumeration is specific rather than generic.

Completeness

The "when" is explicit and detailed ("Use when building ANY macOS app — windows, menus, sandboxing…"), but the "what" — what the skill actually does — is never stated; there is no capability statement at all. Anchor 4 requires both present; anchor 2 ("only 'when' present") fits structurally but its example is vague whereas this 'when' is maximally explicit, placing this between the anchors at 3.

Trigger Term Quality

"building ANY macOS app", "windows", "menus", "sandboxing", "distribution", "touch input" are natural phrases a developer would say when needing this skill. A few common variations are missing ("notarization", "Developer ID", "Catalyst", "menu bar", "Mac"), which fits anchor 4 (good coverage, a few natural terms missing) rather than anchor 5's comprehensive synonym coverage.

Distinctiveness Conflict Risk

"ANY macOS app" plus "macOS-specific SwiftUI patterns" carves a clear macOS-only niche with distinct triggers, but any macOS SwiftUI or iOS-adjacent task would also plausibly trigger a general SwiftUI/iOS skill, so overlap risk with closely related skills remains — anchor 4 rather than anchor 5's minimal conflict risk.