CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/chrome-extension-messaging-tests

Asserts Chrome extension message-passing behaviour against a running extension: one-shot `chrome.runtime.sendMessage` plus the literal `return true` that holds the response channel open for an async `sendResponse`, `chrome.tabs.sendMessage` into one tab's content script, long-lived `chrome.runtime.connect` ports and their `onDisconnect` triggers, web-page messages gated by `externally_connectable`, and `chrome.runtime.connectNative` native-messaging hosts. Covers the payload rules a test must respect (Chrome uses JSON serialization rather than structured clone, so `Map` / `Set` / `Date` do not round-trip; maximum message size is 64 MiB) and the first-listener-wins rule when several `onMessage` listeners are registered. Scope is messaging behaviour on an already-running extension, not the install or reload step. Use when a message reaches no listener, a `sendResponse` callback never fires, a port disconnects mid-test, or a page origin has to be proven allowed before publishing.

Quality

91%

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

78%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: dense with platform-specific gotchas, a clear multi-step workflow with a self-check step, an anti-patterns table, and exemplary progressive disclosure to two verified one-level-deep references. The deductions are minor: duplicated reference URLs, the async-trap point restated three times, and two incomplete inline code examples (undefined helper, orphaned farewell field) that keep the guidance from being fully copy-paste ready.

Suggestions

Cut the duplication between the inline footnote link definitions ([cr-msg], [cr-runtime], [cr-tabs], etc.) and the References section — keep one form of each URL to trim the token cost of the conciseness dimension's main redundancy.

Make the two inline code examples self-contained: define or inline the `sendFromContentScript` helper in the runtime test snippet, and either show a listener that sets `farewell` or drop `JSON.parse(response.farewell)` from the tabs example.

Add an explicit run-and-fix step after authoring (e.g., 'run the new tests; if the async-trap case fails, re-check the listener's return value') to close the workflow's missing feedback loop.

DimensionReasoningScore

Conciseness

The body is largely lean and earns its tokens with non-obvious specifics Claude likely does not know cold ("a literal true (not just a truthy value)", the JSON-serialization payload table, "Opening a port no longer resets the timers", Chrome 148 promise-return support), which matches 'Efficient; minor instances of over-explanation that could be trimmed'. It is not a 5 because of real duplication: the same Chrome doc URLs appear both inline as footnote definitions ([cr-msg], [cr-runtime], etc.) and again in the References section, and the async-listener trap is explained in prose, restated in two Anti-patterns rows, and enumerated again in the worked example. It is not a 3 because nearly all content is skill-specific and nothing explains generic background concepts.

4 / 5

Actionability

Mostly executable: the runtime sender/listener pair, the equality-matcher test, the tabs rejection targets, the payload table, and the Anti-patterns 'Fix' column are concrete and near copy-paste ready, matching 'Mostly executable guidance; concrete code or commands with minor gaps'. It is not a 5 because of those gaps: the test snippet calls an undefined helper `sendFromContentScript({ greeting: 'hello' })`, and the tabs example reads `JSON.parse(response.farewell)` with no listener shown that ever sets a `farewell` field. It is not a 3 because the code is real (not pseudocode) and the ports/external/native recipes delegated to the two references are complete there.

4 / 5

Workflow Clarity

The 'How to use' section gives a clear 6-step sequence (identify shape → confirm running → write pair → assert full object → apply payload guardrails → 'Re-check the draft against the Anti-patterns table before committing'), with the final step acting as an explicit self-validation checkpoint — matching 'Clear sequence with most checkpoints present; minor validation gaps'. It is not a 5 because there is no run-and-fix feedback loop after authoring (e.g., what to do when the new tests fail), only a pre-commit re-check. It is not a 3 because the sequence is coherent and does include an explicit checkpoint step.

4 / 5

Progressive Disclosure

The SKILL.md is an overview that keeps the two simplest shapes inline and moves the deeper material to exactly two companion files, both verified to exist and contain precisely what is advertised ('the wrong-port-name disconnect test, and the 30-second idle-termination interaction' is indeed in long-lived-ports.md; the per-OS native-host manifest table is in cross-boundary-messaging.md). Each is signaled with a descriptive bullet in the body and again in References, and neither file references anything further — one level deep, easy to navigate. This matches the top anchor exactly.

5 / 5

Total

17

/

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: third-person, concrete, comprehensive across all five messaging shapes plus payload and listener rules, with an explicit symptom-based 'Use when' clause and an explicit scope boundary against the adjacent install/reload skill. Every clause carries information; there is no filler despite the length.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete actions covering the full domain: "one-shot chrome.runtime.sendMessage plus the literal return true", "chrome.tabs.sendMessage into one tab's content script", "long-lived chrome.runtime.connect ports and their onDisconnect triggers", "web-page messages gated by externally_connectable", and "chrome.runtime.connectNative native-messaging hosts", plus payload rules ("Map / Set / Date do not round-trip; maximum message size is 64 MiB"). This matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage' — every messaging shape plus payload constraints is named. It is not a 4, because there are no gaps in capability coverage; the five shapes plus payload rules plus the first-listener-wins rule exhaust the skill's stated scope.

5 / 5

Completeness

It explicitly answers "what" ("Asserts Chrome extension message-passing behaviour against a running extension" with the five enumerated shapes and payload rules) and "when" (the explicit "Use when..." clause with four concrete trigger phrases). This is the anchor 'Clearly and explicitly answers both what AND when with concrete trigger phrases'. It is not a 4 because the 'when' clause is already maximally explicit — symptom-driven, not generic.

5 / 5

Trigger Term Quality

The closing clause supplies natural symptom phrases a developer would actually say: "Use when a message reaches no listener, a sendResponse callback never fires, a port disconnects mid-test, or a page origin has to be proven allowed before publishing" — alongside the API names (chrome.runtime.sendMessage, chrome.runtime.connect, externally_connectable, connectNative) that serve this domain's file-extension role. Coverage includes both symptom synonyms and API identifiers. It is not a 4 because no clearly natural phrasing family for these failure modes is missing: silent no-response, dead callback, mid-test disconnect, and allow-list verification are all present.

5 / 5

Distinctiveness Conflict Risk

The niche is unambiguous (Chrome extension message-passing test assertions) and it even draws the boundary against the nearest competing skill: "Scope is messaging behaviour on an already-running extension, not the install or reload step." That is a clear niche with distinct triggers and minimal conflict risk — an install/reload skill would trigger on different symptoms ("an extension that is absent or shows an error"). Not a 4, because the explicit scope boundary removes even the minor overlap risk with closely related extension-testing skills.

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

On this page