Conciseness

The body is a lean catalogue: a dense table of capabilities with entry points, copy-paste commands, a short decision guide, and a reference list. Every line carries information Claude doesn't have (bandpass frequencies, ADR numbers, port numbers); there is no explanation of concepts Claude already knows and no padding. This matches the 5 anchor ('every token earns its place') rather than 4, which would require over-explanation to trim.

Actionability

The 'Quick recipes' block gives fully executable commands covering the common cases — 'docker run -p 3000:3000 ruvnet/wifi-densepose:latest', 'cd v2 && cargo run -p wifi-densepose-sensing-server', 'node scripts/rf-scan.js --port 5006', 'python examples/ruview_live.py' — and the table maps each application to a concrete entry point. Matches the 5 anchor (copy-paste ready, common cases covered); only trivially ambiguous details like where 'v2' lives keep it from being beyond reproach, not enough to drop to 4.

Workflow Clarity

Recipes are unambiguous one-shot commands with implicit ordering (e.g. 'cd v2' then cargo run; embed a model then build an index), and the 'Picking the right modality' section sequences the decision from situation to application. However, multi-step paths like '--embed' followed by '--build-index env' have no validation/checkpoint steps (e.g. confirming the server is consuming CSI before building an index), which fits anchor 4 ('clear sequence, minor validation gaps') rather than 5. No destructive or batch operations exist that would cap the score at 3.

Progressive Disclosure

The body is a well-organized overview with clearly signaled one-level-deep references: 'README.md', 'docs/user-guide.md', 'docs/wifi-mat-user-guide.md', named ADRs, 'examples/... each has a README', and sibling skills (ruview-quickstart, ruview-hardware-setup, ruview-model-training, ruview-advanced-sensing) — all referenced by exact path, none nested. It falls short of anchor 5 because some reference sections are dense pointer lists (e.g. the ADR number enumeration '021...094' and the bare module path) that would be easier to navigate if grouped by task; anchor 4 ('good structure, references mostly clear, minor organization gaps') fits best.

Specificity

The description enumerates all eight concrete application areas — 'presence/occupancy, breathing & heart rate, activity & fall detection, 17-keypoint pose estimation (WiFlow), sleep monitoring & apnea screening, environment mapping, Mass Casualty Assessment (MAT), and the 3D point-cloud fusion demo' — matching the body's catalogue exactly, with no vague filler. This matches the 5 anchor (multiple specific concrete items, comprehensive coverage); a 4 would require minor gaps in coverage, but the list covers the skill's full scope.

Completeness

Both parts are explicit: what — 'Run RuView sensing applications'; when — 'Use when someone wants to actually *do* something with a working RuView setup'. The when-clause is present but generic ('actually *do* something') rather than naming concrete triggers, which fits anchor 4 ('when' could be more explicit or specific) rather than 5 (concrete trigger phrases) and clearly above 3 (when is not merely implied).

Trigger Term Quality

Natural user phrases are well covered: 'presence/occupancy', 'breathing', 'heart rate', 'fall detection', 'sleep monitoring', 'apnea', 'pose estimation'. A few common variants are absent (e.g. 'vital signs', 'through-wall'/'see through walls', 'person counting'), so it sits between anchor 3 and 5 — closer to 4 (good keyword coverage, a few natural terms missing) than 5 (comprehensive synonyms/extensions).

Distinctiveness Conflict Risk

Proper nouns ('RuView', 'WiFlow', 'MAT') give it a clear niche with minimal conflict against unrelated skills. Minor overlap risk remains with closely related sibling skills (ruview-quickstart, ruview-advanced-sensing) since 'do something with a working RuView setup' could also lead a user to the quickstart skill — anchor 4 ('mostly distinct; minor overlap risk with closely related skills') rather than 5.