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. Use when a feature pushes updates over `text/event-stream` and the reconnect interval, `Last-Event-ID` replay, or per-origin connection ceiling has no coverage.

70

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

72%

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

The body is well-structured with executable Playwright code, a clear one-level-deep reference to a verified recipes file, and useful anti-pattern guidance. It loses points on conciseness (some explanatory prose Claude already knows) and workflow clarity (the main steps are parallel test recipes whose explicit recovery loops are deferred to the bundled file).

Suggestions

Tighten the Limitations section: keep only the testing-relevant constraint (the server must persist event IDs for Last-Event-ID replay to work) and drop generic SSE background like proxy buffering and lack of binary support, which Claude already knows.

Add an explicit validate→fix→retry loop inline in the main workflow (e.g., 'if a readyState/replay assertion fails, consult the Anti-patterns table, fix the server emission, then re-run') instead of deferring all recovery guidance to the recipes file.

Fold the Anti-patterns 'Why it fails' column into the 'Fix' column to remove explanatory prose and keep the table action-only.

DimensionReasoningScore

Conciseness

The body is mostly efficient (compact field/state tables, executable code, a pointer to deeper recipes), but includes prose Claude largely already knows — the Limitations section on proxy buffering and lack of binary support, and the "Why it fails" column of the Anti-patterns table. This matches score 2 ('mostly efficient but includes some unnecessary explanation or could be tightened') rather than the lean, every-token-earns-its-place score 3.

2 / 3

Actionability

Step 2 and Step 3 give fully executable Playwright TypeScript tests with imports and expect() assertions, and Step 1 shows a concrete stream-format example; the bundled recipes add executable Python/TS reconnect tests. This matches the score-3 anchor (fully executable, copy-paste ready), clearly above score 2's pseudocode/missing-details anchor.

3 / 3

Workflow Clarity

Steps are clearly sequenced (Step 1–3) and each test carries assertion-based validation, but the three steps are parallel independent test recipes rather than a dependent process, and the explicit validate→fix→retry feedback loop lives only in the bundled recipes file ("if it is not, the server is not persisting event IDs - fix the store") rather than the main flow. This fits score 2 ('sequence present but checkpoints missing or implicit') below score 3's inline recovery loops.

2 / 3

Progressive Disclosure

The body is a clear overview (When to use, Step 1–3, Anti-patterns, Limitations) with a well-signaled one-level-deep pointer — "Reconnect-with-replay via Last-Event-ID, the retry: interval, 204 No Content disable, and the HTTP/1.1 connection-pool ceiling are in references/sse-test-recipes.md" — to a real bundle file (verified present). Content is appropriately split with easy navigation, matching the score-3 anchor.

3 / 3

Total

10

/

12

Passed

Description

100%

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

The description is specific and concrete, uses natural trigger terms (SSE, Server-Sent Events, EventSource, text/event-stream), provides an explicit 'Use when…' clause, and explicitly disambiguates from the websocket-tests skill. It is written in imperative/third-person voice with no over-claims or padding.

DimensionReasoningScore

Specificity

Lists multiple concrete surfaces and actions — "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", and "HTTP/1.1 connection-pool limits" — plus the tool split ("Use Playwright for browser-side, raw HTTP client for server-side"). This matches the score-3 anchor (multiple specific concrete actions), well above score 2's 'names domain and some actions but not comprehensive'.

3 / 3

Completeness

Explicitly answers both halves: what ("Test Server-Sent Events (SSE) flows…") and when ("Use when a feature pushes updates over text/event-stream and the reconnect interval, Last-Event-ID replay, or per-origin connection ceiling has no coverage."). The explicit "Use when…" clause satisfies the score-3 anchor and clears the guideline that a missing Use-when clause caps completeness at 2.

3 / 3

Trigger Term Quality

Covers the natural terms a user would actually say — "Server-Sent Events (SSE)", "EventSource", "text/event-stream", "Last-Event-ID" — alongside variations, matching the score-3 anchor's good coverage. It is above score 2 ('some relevant keywords but missing common variations') since both the acronym and full name plus the API and content-type are present.

3 / 3

Distinctiveness Conflict Risk

It carves a clear one-way niche and actively prevents misrouting: "one-way server-to-client push only (not bidirectional, use websocket-tests for client-to-server messaging)". This matches the score-3 anchor (clear niche with distinct triggers; unlikely to conflict), above score 2's 'somewhat specific but could still overlap'.

3 / 3

Total

12

/

12

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Reviewed

Table of Contents