Conciseness

The body is largely lean (library table, code-first steps, an anti-patterns table), but re-explains protocol basics Claude already knows, e.g. the handshake header list ('Sec-WebSocket-Key: base64 16-byte nonce', 'Sec-WebSocket-Version: 13') and 'Control frames include ping (0x9), pong (0xA), close (0x8); payloads <= 125 bytes'. These are borderline-useful as assertion checklists, so this is minor over-explanation (anchor 4) rather than the fully lean anchor 5.

Actionability

Most examples are concrete, executable Jest-style tests (handshake accept-hash assertion, subprotocol negotiation, pong-within-5s race, Playwright framesent hook), but the reconnect example depends on undefined helpers ('createReconnectingClient', 'waitForState', 'bounceServer') and the handshake test reaches into ws internals ('ws._req?.getHeader'). That is 'mostly executable with minor gaps' — anchor 4, not the copy-paste-complete anchor 5.

Workflow Clarity

Steps 1-6 give a clear, ordered sequence (pick lib, handshake, subprotocol, keepalive, reconnect, browser e2e) and the anti-patterns table maps failures back to fixes. However, there is no explicit validate-on-failure loop in the body (the only recovery guidance, 'if it is 1006 ... fix the server shutdown path', lives in the reference file), so it fits anchor 4 ('most checkpoints present; minor validation gaps') rather than anchor 5's explicit feedback loops.

Progressive Disclosure

The SKILL.md body is a well-organized overview and the two deep recipes (close-code matrix, maxPayload/1009 backpressure) are split into references/websocket-test-recipes.md, which exists in the bundle and is clearly signaled with a markdown link naming exactly what it contains ('The close-frame status-code matrix (1000/1001/1002/1006/1011) and the backpressure / large-message ... recipes are in [references/websocket-test-recipes.md]'). One level deep, no buried or nested references — matches anchor 5.

Specificity

The description lists multiple concrete, domain-covering actions: 'connect, send and receive messages, ping/pong, close codes, reconnect after the server drops, subprotocols and backpressure', plus named client libraries. This matches anchor 5 (multiple specific concrete actions, comprehensive coverage); it is clearly above anchor 4 because no significant capability of WebSocket testing is left unmentioned.

Completeness

Both halves are explicit: the what is the concrete action list ('connect, send and receive messages, ping/pong, close codes, reconnect ... subprotocols and backpressure') and the when is an explicit trigger clause ('Use whenever the task is to test a WebSocket endpoint or real-time server'). This is the anchor 5 pattern; anchor 4 would require the when-clause to be less explicit.

Trigger Term Quality

It covers the natural phrases a user would say — 'test a WebSocket endpoint', 'real-time server', 'ping/pong', 'close codes', 'reconnect', 'subprotocols', 'backpressure' — and includes the library names users would mention ('ws', 'Python websockets', 'Playwright'). Comprehensive natural-term coverage matches anchor 5 rather than anchor 4's 'a few natural terms missing'.

Distinctiveness Conflict Risk

The WebSocket-specific triggers (close codes, ping/pong, subprotocols) form a clear niche, but the broadened phrase 'or real-time server' overlaps with closely related skills such as the server-sent-events and gRPC-streaming tests this skill itself cross-references — a minor overlap risk with closely related skills, i.e. anchor 4. It is above anchor 3 because the dominant triggers are unambiguous, and below anchor 5 because 'real-time server' alone could plausibly fire a one-way-push (SSE) testing task.