Conciseness

The body is lean and assumes Claude's competence — no explanation of what SwiftUI or Instruments are — but reference pointers repeat: "references/profiling-intake.md" is cited in the Quick start, section 1, and section 3, and "references/code-smells.md" in the Quick start, sections 2 and 5, and the References section. Efficient with minor duplication that could be trimmed, matching the score-4 anchor rather than score 5's every-token-earns-its-place.

Actionability

Concrete, specific guidance throughout — "Unstable identity in lists and `ForEach`", "Move heavy work out of `body` into derived state...", "Downsample images before rendering", "Use `equatable()` only when equality is cheaper than recomputing the subtree" — with details correctly delegated to the reference files. Not a 5 because several directives (e.g., "Stabilize identities for `ForEach` and lists") name the fix without the how, which lives off-page; not a 3 since nothing is pseudocode or vague.

Workflow Clarity

A clearly sequenced 6-phase workflow (Intake → Code-First Review → Guide to Profile → Analyze → Remediate → Verify) with a decision point ("If code review does not explain the issue, ask for runtime evidence"), explicit verification (re-run the same capture and compare with baseline metrics), and a call-out loop in section 4 for when profiling is still insufficient. Matches the score-5 anchor: clear sequence, explicit validation steps, and feedback loops.

Progressive Disclosure

The body is an overview that points to 7 real one-level-deep files under references/ (verified: code-smells.md, profiling-intake.md, report-template.md, plus four Apple/WWDC docs), each clearly signaled by purpose at point of use and again in a References section; grep confirms no reference file points to another, so there is no nesting. Clean split matching the score-5 anchor.

Specificity

Quotes multiple concrete actions — "Audit and improve SwiftUI runtime performance", "diagnose slow rendering, janky scrolling, high CPU/memory usage, excessive view updates, or layout thrash", "provide guidance for user-run Instruments profiling" — with comprehensive symptom coverage. Not a 4 because the action list is comprehensive rather than having minor gaps; not below 5 since every capability stated is concrete.

Completeness

Explicitly answers both: what ("Audit and improve SwiftUI runtime performance from code review and architecture") and when ("Use for requests to diagnose slow rendering, janky scrolling..."), plus a conditional trigger for profiling guidance. Matches the score-5 anchor of clear 'what' and 'when' with concrete trigger phrases; nothing is only implied.

Trigger Term Quality

Natural user phrasing is thoroughly covered: "slow rendering", "janky scrolling", "high CPU/memory usage", "excessive view updates", "layout thrash", "SwiftUI apps", "Instruments profiling". These are exactly the words a user with a SwiftUI performance problem would say, including synonyms; not a 4 since no common variation is missing.

Distinctiveness Conflict Risk

The SwiftUI-specific symptom triggers ("layout thrash", "excessive view updates" in "SwiftUI apps") carve a clear niche, but phrases like "code review" and "high CPU/memory usage" create minor overlap risk with general code-review or profiling skills. Mostly distinct with minor overlap risk — the score-4 anchor — rather than score 5's minimal conflict risk.