Conciseness

The body is lean: tables, a decision tree, checklists, and one executable code block, with no explanation of concepts Claude already knows. Not 5 because there is minor redundancy — the Quick Reference table repeats the Decision Tree's problem-to-reference routing — and a few 'Profiling Ground Rules' entries (Release configuration, representative data) restate knowledge Claude already holds. Not 3 because these are small trimmings, not padded sections.

Actionability

Concrete and specific throughout: named instruments per problem, quantified thresholds ('UI hangs over 250 ms', 'synchronous work on the main thread over 100 ms'), a menu path ('Scheme > Run > Diagnostics'), and a complete, copy-paste-ready MetricKit Swift implementation. Not 5 because how to actually launch and drive a profiling session is left entirely to the references — the body says 'read references/time-profiler.md' but gives no inline command or procedure for the common first step.

Workflow Clarity

The 6-step workflow has an explicit validation checkpoint ('Re-profile or add a repeatable measurement to confirm the improvement'), routes via the decision tree, and supplies checklists for complex processes (Review Checklist), matching the anchor-5 pattern of sequence + validation + checklists. Not 4 because the verification step is explicit and loop-like rather than implicit; there is no destructive/batch operation that would require a cap.

Progressive Disclosure

The body is an overview that routes to four real, verified reference files (time-profiler, memory-profiling, launch-optimization, energy-diagnostics), all exactly one level deep (grep of the reference files shows no nested references). Navigation is well-signaled in three places (Decision Tree, Quick Reference, References section with one-line summaries). Not 4 because the split is clean and every routing signal is explicit with no organization gaps.

Specificity

Names the domain ('Apple platform apps') and concrete tools ('Instruments, Xcode diagnostics, and MetricKit', 'os_signpost and measurement hooks') rather than vague language, but the action itself is a single verb ('Guide performance profiling') — it describes one activity with specific instrumentation rather than several distinct actions like the anchor-5 example ('Extract... fill... merge... convert...'). Not 3 because the tool list and 'adding os_signpost hooks' go well beyond 1-2 generic actions; not 5 because it lacks a list of multiple distinct capabilities.

Completeness

Explicitly answers 'what' ('Guide performance profiling for Apple platform apps with Instruments, Xcode diagnostics, and MetricKit') and 'when' with a literal 'Use when investigating...' clause followed by concrete trigger phrases. This matches the anchor-5 example structure exactly; a missing or weak trigger clause would cap it at 3, which does not apply here.

Trigger Term Quality

Eleven concrete trigger phrases — 'app hangs, stutters, high CPU, memory leaks, memory growth, OOM crashes, slow launch, battery drain, thermal issues, App Store performance readiness' — include natural synonyms (hangs/stutters, leaks/growth) users would actually say when they need this skill. Not 4 because coverage is comprehensive with synonym variation, matching the anchor-5 pattern even without file extensions (which are inapplicable to this domain).

Distinctiveness Conflict Risk

Clear niche (Apple-platform performance with Instruments/MetricKit) and highly specific triggers (OOM crashes, thermal throttling, os_signpost) make wrong-skill triggering unlikely. Not 5 because a closely related skill (e.g., general Swift optimization or Apple debugging) would share meaningful trigger overlap with terms like 'high CPU' or 'memory leaks', leaving minor conflict risk with adjacent skills.