Conciseness

The body is reference-dense and assumes competence: almost every section is a short code example or list with minimal prose, and hard-to-recall facts are stated tersely ("SceneKit renders a maximum of 8 lights per node", "Do not use SCNScene.Attribute.unit"). Minor over-explanation remains, e.g., inline comments like "// Ambient: uniform, no direction" and "Reusable, composable animation objects attached to nodes" restate things Claude knows, so it is efficient with a few trimmable spots rather than perfectly lean.

Actionability

Nearly every section provides copy-paste-ready executable Swift covering the common cases: SCNView setup, scene loading with error handling, transforms, materials/PBR, all light types with parameters, camera configuration, all three animation approaches, physics bodies/forces/collision delegates, particle systems, and SwiftUI SceneView. The Common Mistakes section pairs DON'T/DO code, which is maximally actionable.

Workflow Clarity

The asset-loading workflow has an explicit validation feedback loop: guard the resource URL, load with [.checkConsistency: true], verify required nodes, "stop on a consistency or required-node failure, fix the source asset or import options, then repeat the same check", and "require both export success and a checked reload before commit" for generated .scn files. A 19-item Review Checklist covers the remaining processes. This matches the anchor for clear sequence with explicit validation, error-recovery loops, and checklists.

Progressive Disclosure

The body is a well-navigable overview with a contents list, and advanced topics (custom geometry, shader modifiers, constraints, morph targets, hit testing, scene serialization, render loop delegates, performance, SpriteKit overlay, LOD, Metal shaders) are externalized to one real one-level-deep reference (references/scenekit-patterns.md, verified to exist with a matching 'Scene Serialization' anchor for the body's anchor link). The References section enumerates exactly what the bundle file covers, so the split is appropriate and discovery is easy.

Specificity

The description states concrete actions ("Maintain and extend existing SceneKit 3D scenes and visualizations") and enumerates specific work areas ("SCNView, SCNScene, SCNNode scene graphs, SceneKit geometry/materials/lights/cameras, SCNAction animation, SCNPhysicsBody physics, SCNParticleSystem effects, .scn/.dae/.abc SceneKit assets, shader modifiers, or SwiftUI SceneView"), giving several specific capabilities with minor gaps. It falls short of a 5 because the verbs themselves are limited to 'maintain and extend' rather than a comprehensive list of distinct concrete actions.

Completeness

It explicitly answers 'what' ("Maintain and extend existing SceneKit 3D scenes and visualizations") and 'when' ("Use when working with..." followed by concrete trigger phrases), and additionally clarifies scope boundaries with "route new apps, significant updates, USD/USDZ pipelines, and migration planning toward RealityKit". Both what and when are explicit with concrete triggers.

Trigger Term Quality

Trigger terms are comprehensive for the domain: users naturally mention "SCNView", "SCNScene", "SCNNode", "SCNAction", "SCNPhysicsBody", "SCNParticleSystem", "shader modifiers", "SwiftUI SceneView", and file extensions ".scn/.dae/.abc", plus the generic phrases "3D scenes" and "visualizations". Matches the anchor for comprehensive coverage including synonyms and file extensions.

Distinctiveness Conflict Risk

The description carves a clear niche (maintenance of existing SceneKit code) and explicitly disambiguates from the closely related RealityKit skill ("route new apps, significant updates, USD/USDZ pipelines, and migration planning toward RealityKit"), minimizing wrong-skill triggering. SceneKit-specific class names make conflict with other skills virtually nil.