CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/server-sent-events-tests

Test Server-Sent Events (SSE) flows, one-way server-to-client push only (not bidirectional, use websocket-tests for client-to-server messaging): `EventSource` API on the browser side (`onmessage`, `onerror`, `readyState` 0/1/2), event stream format (`data:`, `event:`, `id:`, `retry:`), `Last-Event-ID` reconnect-with-replay header, content-type `text/event-stream`, and HTTP/1.1 connection-pool limits. Use Playwright for browser-side, raw HTTP client for server-side stream tests; k6 load testing (concurrent-stream capacity, connection churn, HTTP/1.1 vs HTTP/2 ceiling) lives in references/sse-load.md. Use when a feature pushes updates over `text/event-stream` and the reconnect interval, `Last-Event-ID` replay, per-origin connection ceiling, or concurrent-stream capacity has no coverage.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A strong, well-structured body: executable Playwright examples, a sequenced test workflow, and clean two-file progressive disclosure with verified reference targets. The only real cost is spec-knowledge tables (field meanings, readyState values) that re-tread what Claude already knows.

Suggestions

Cut or compress the stream-format field table and the `readyState` 0/1/2 table — Claude already knows this spec detail; keep only non-obvious testing implications (e.g. multiple `data:` line joining, comment-line heartbeats under proxies).

Add a short "when a step's test fails" loop that maps a failing assertion to the anti-patterns table (e.g. events buffered indefinitely → check `\n\n` terminator) to close the workflow-clarity validation gap.

Replace the prose intro paragraph (which restates the description) with a one-line pointer to the WHATWG spec already linked in References.

DimensionReasoningScore

Conciseness

The body assumes SSE knowledge and has no "what is SSE" padding, but the stream-format field table (`data:`/`event:`/`id:`/`retry:` meanings) and the `readyState` 0/1/2 table restate WHATWG spec knowledge Claude already has — minor over-explanation that could be trimmed, matching the 4 rather than the lean 5 anchor.

4 / 5

Actionability

Two complete, copy-paste-ready Playwright tests with real assertions (`expect(transitions).toEqual([0, 1, 2])`), a concrete wire-format example stream, and an anti-patterns table pairing each failure with a specific fix. Covers the common cases fully executably.

5 / 5

Workflow Clarity

A clear sequenced workflow (server-side format → browser test → readyState lifecycle → deeper recipes) where each step embeds assertion-based validation, and the anti-patterns table supplies failure→fix guidance. Not a 5 because there is no explicit validate→fix→retry loop telling Claude what to do when a step's test fails.

4 / 5

Progressive Disclosure

Core tests stay inline while deeper material (reconnect/retry/204/connection-pool recipes, k6 load testing) is split into two real, one-level-deep reference files, each signposted in both a dedicated section and the References list with a description of its contents. Navigation is easy and the split is appropriate.

5 / 5

Total

18

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary description: concrete capabilities, tooling responsibilities split (Playwright vs raw HTTP vs k6), explicit use-when triggers with concrete coverage signals, and explicit disambiguation from the WebSocket alternative. Dense but not padded — every clause names a testable surface.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — testing the `EventSource` API (`onmessage`, `onerror`, `readyState` 0/1/2), the stream format fields (`data:`, `event:`, `id:`, `retry:`), `Last-Event-ID` reconnect-with-replay, content-type `text/event-stream`, HTTP/1.1 connection-pool limits, Playwright browser tests, raw HTTP server tests, and k6 load testing — with no coverage gaps, matching the comprehensive anchor.

5 / 5

Completeness

Explicitly answers both what (the enumerated SSE test surfaces and tooling split) and when ("Use when a feature pushes updates over `text/event-stream` and the reconnect interval, `Last-Event-ID` replay, per-origin connection ceiling, or concurrent-stream capacity has no coverage"), with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural user terms appear with synonyms and shorthand: "Server-Sent Events (SSE)", "EventSource", "text/event-stream", "reconnect interval", "replay", "connection ceiling", "load testing". No common variation is missing, matching the comprehensive-synonyms anchor.

5 / 5

Distinctiveness Conflict Risk

Occupies a clear one-way-push niche and explicitly routes the main overlap away ("not bidirectional, use websocket-tests for client-to-server messaging"), so the risk of triggering for the wrong streaming skill is minimal.

5 / 5

Total

20

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents