Conciseness

Every fact earns its place (no concept padding, specific gotchas like 'Physics bitmask issues (default 0xFFFFFFFF)'), but the same routing table is rendered five ways: the Quick Reference table, External Routes prose, the dot-graph Decision Tree, the numbered Decision Tree list, and Example Invocations. The dot graph and the numbered list immediately below it are literal duplicates of the same 15 routes, so the document could be roughly 40% shorter.

Actionability

Routing is concrete and executable — exact file paths per symptom ('Physics contacts not firing → skills/spritekit-diag.md') plus actionable specifics ('TCTouchController.isSupported gate + connect/render/touch-routing setup', 'Half-screen collider shapes... never small circles', '[weak self] in all SKAction.run closures'). Not a 5: there is no code anywhere in the body, and external-suite pointers like 'See axiom-graphics (skills/scenekit.md)' name a destination without invocation mechanics beyond the auditor inline note.

Workflow Clarity

This is a single-task router skill and its single action — route a stated need to the right reference — is unambiguous. The decision procedure is explicit (framework choice → need → exact file), consistent across every presentation, and no destructive or batch operation exists that would demand validation checkpoints.

Progressive Disclosure

Textbook router structure: an overview body with clearly signaled, one-level-deep backticked references and organized lookup sections. Held below 5 because the referenced bundle files (skills/spritekit.md, skills/game-input.md, skills/spritekit-ref.md, skills/spritekit-diag.md) are not present in the provided bundle, so the navigation targets dangle and cannot be verified.

Specificity

Names several concrete, framework-scoped activities — 'building ANY 2D or 3D game with SpriteKit, SceneKit, or RealityKit', 'adding touch controls or game controller support' — plus specific API names (TouchController, GCController). Not 5 because 'Covers scene graphs, ECS, physics, actions, game loops, rendering' is topic enumeration rather than concrete actions, and capabilities the body routes (diagnostics, Metal porting, IAP) are unmentioned; not 3 because it goes well beyond 1-2 actions with named specifics.

Completeness

Both halves are explicit: 'Use when building ANY 2D or 3D game with SpriteKit, SceneKit, or RealityKit, or adding touch controls or game controller support' answers when with concrete trigger phrases, and 'Covers scene graphs, ECS, physics, actions, game loops, rendering, TouchController, GCController' answers what it does.

Trigger Term Quality

'2D or 3D game', 'SpriteKit', 'SceneKit', 'RealityKit', 'touch controls', and 'game controller' are exactly the natural phrases a user would say when needing this skill, and they include the framework synonyms for the whole domain. Coverage is comprehensive; no common variation of the domain's triggers is missing.

Distinctiveness Conflict Risk

Apple game frameworks plus touch/controller input form a clear, well-named niche with minimal conflict risk. Not 5 because SceneKit/RealityKit/rendering triggers overlap with the sibling graphics suite — the body itself routes those topics to axiom-graphics — so a request in that overlap zone could plausibly trigger either skill.