Conciseness

The body is a dense router that mostly avoids explaining known concepts, but it could be tightened: the 'dot' Decision Tree duplicates roughly 20 rows of the Quick Reference table in a second format, and Anti-Rationalization rows embed detailed technical caveats (e.g. the Xcode 27 '@State is lazy' row's private/deployment-target gating and TN3211 references) that belong in the referenced files. This fits anchor 3 ('mostly efficient but could be tightened') better than anchor 4's 'minor instances'.

Actionability

As an instruction/router skill, every entry gives a concrete, executable destination: named files ('See `skills/nav.md`'), named agents ('Launch `swiftui-nav-auditor` agent'), or copy-paste commands ('/axiom:audit swiftui-performance', '/skill axiom-accessibility'). Specific examples cover the common cases, matching anchor 5.

Workflow Clarity

Routing is unambiguous via the symptom-to-reference table, with explicit escalation paths ('View update still broken after debugging → `skills/debugging-diag.md`') and an ordered conflict-resolution procedure with a check-before-escalate condition ('Only use axiom-performance if domain fixes don't help'). Minor gaps — not every table row has an escalation path and no guidance for multiple co-occurring symptoms — keep it at anchor 4 rather than 5.

Progressive Disclosure

The body is a well-sectioned index (Quick Reference, Non-SwiftUI Routes, Conflict Resolution, Decision Tree, Automated Scanning, Anti-Rationalization) with clearly signaled one-level references ('See `skills/layout.md`') and explicit out-of-scope routing to sibling suites. However, the `skills/*.md` targets do not exist within this skill's bundle (no references/ or skills/ directory alongside SKILL.md), so the split cannot be verified against actual files — anchor 4 ('good structure, minor organization gaps') rather than anchor 5.

Specificity

The description enumerates comprehensive, concrete scope ("views, navigation, layout, animations, gestures, debugging, iOS 26 features, iPhone Duo, view-level performance, feature architecture") but the action verbs ("building, fixing, or improving") are generic. It lists several specific coverage areas with minor gaps, matching anchor 4 rather than anchor 5's fully concrete action list, and well above anchor 3's '1-2 concrete actions'.

Completeness

The 'when' is maximally explicit ("Use when building, fixing, or improving ANY SwiftUI UI") but the 'what' is only weakly implied: nothing states what the skill actually provides (reference material, troubleshooting, routing). This matches anchor 3 (capability implied rather than stated) — not anchor 4, which requires both 'what' and 'when' present, and not anchor 2, since the enumerated scope does convey substantial capability information.

Trigger Term Quality

Strong natural keyword coverage ("SwiftUI", "navigation", "animations", "gestures", "debugging", "layout") that users would actually say. However, "previews" — a major body topic with two dedicated reference files (skills/previews.md, skills/previews-ref.md) and a natural user trigger — is missing, so it falls short of anchor 5's comprehensive coverage including synonyms.

Distinctiveness Conflict Risk

"SwiftUI" is a clear, distinct niche, and "view-level performance" explicitly scopes the performance overlap away from a general profiling skill. Conflict risk with sibling suites (UIKit, design) is minimal because their trigger terms are absent; this matches anchor 5's clear niche with distinct triggers.