Conciseness

The ~80-line body contains only project-specific operational knowledge (e.g., 'Protocol landscape names are opposite CoreDevice physical names; the inner panel also has a rotated natural axis', 'Safari's cover UI excludes upside-down portrait') with no explanations of concepts Claude already knows; every sentence carries a command, constraint, or non-obvious fact.

Actionability

Commands are copy-paste ready ('node packages/serve-sim/dist/serve-sim.js fold 180 -d <udid>', 'xcrun devicectl device motion hinge-angle --device <udid> --timeout 5') with the placeholder convention stated up front ('Use the actual server port and Duo UDID in subsequent commands'), and pass criteria are quantified ('Marker centers must land within two output pixels of their rendered centers; hardware anchors must land on opaque model pixels').

Workflow Clarity

Each workflow is sequenced with preconditions (rebuild then restart the server; 'Bring Safari to the foreground on the Duo before running'), explicit validation ('Compare the preview's selected display with the latest SpringBoard DisplayContentMode event containing .cover:pri or .inner:pri'), and a feedback loop ('Stop on a failed assertion and inspect the reported physical, UI, and model orientations before retrying'), matching the top anchor's validate-inspect-retry pattern.

Progressive Disclosure

The body stays an operational overview and pushes the 218-line feature checklist to references/expected-behavior.md and historical results to references/verification.md — both real files, clearly signaled with in-context links, exactly one level deep — while executable helpers live in scripts/; nothing that belongs in a reference is inlined and navigation is easy.

Specificity

The what-clause lists concrete verification targets ('Verify serve-sim Duo folding, guest orientation, and model rotation against a local iOS Simulator') but relies on a single verb and leaves display/panel-selection verification only implied via the when-clause, so coverage is several specific actions with a minor gap rather than the comprehensive multi-action listing of a 5.

Completeness

Both halves are explicit: a clear what ('Verify serve-sim Duo folding, guest orientation, and model rotation against a local iOS Simulator') and a concrete when ('Use after changing Duo pose, orientation, or display-selection behavior, or when investigating regressions in those features'), matching the top anchor's what-plus-concrete-trigger-phrase pattern.

Trigger Term Quality

Natural terms a user would say are present ('Duo', 'folding', 'orientation', 'model rotation', 'regressions', 'iOS Simulator'), but common variations such as 'hinge', 'fold angle', 'landscape/portrait', or 'panel selection' are absent, stopping short of the synonym-level coverage of a 5.

Distinctiveness Conflict Risk

The 'serve-sim Duo' / 'local iOS Simulator' niche is highly specific with distinct triggers (Duo pose, orientation, display-selection, regressions); virtually no other skill would match this description, fitting the clear-niche anchor.