CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/electron-playwright

Use whenever an Electron desktop app needs end-to-end tests, or a Spectron suite must be migrated: Playwright's _electron.launch, renderer windows as Pages, main-process checks via electronApp.evaluate, and IPC and DOM assertions from one suite.

Quality

86%

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 highly actionable, well-sequenced skill with excellent progressive disclosure — every step has executable code and detail is properly offloaded to two real reference files. The main weakness is token efficiency: several body explanations duplicate the API reference file and restated doc quotes that could be trimmed.

Suggestions

Trim the 'What's going on' bullets in Step 2 and the evaluate/firstWindow/browserWindow explanations in Steps 4–6 to one-line pointers into references/electron-ci-and-api.md, since that file already carries the full API table — this removes the duplicated doc quotes without losing information.

Compress the Overview's 'three sanctioned test stacks' framing and merge the thin Step 9 (results parsing) into Step 8's running section to cut prose that does not change what Claude does.

Add an explicit validation checkpoint after Step 7/8 (e.g., 'confirm npx playwright test exits 0 before wiring CI') so the install→config→run→CI sequence has a concrete gate before the CI step.

DimensionReasoningScore

Conciseness

The body is mostly efficient, but the "What's going on" bullets restate documented API behavior (e.g., firstWindow "waits for the first application window to be opened", evaluate's argument semantics) that is duplicated in the API table in references/electron-ci-and-api.md, and the Overview/Step 9 prose could be tightened. This is more than the minor trimmable instances of the 4 anchor, but well above the padded verbosity of 2.

3 / 5

Actionability

Fully executable throughout: npm install command, a complete first-test file, per-OS packaged-binary path resolution, a full playwright.config.ts, and run/trace CLI commands — copy-paste ready and covering the common cases (dev launch, packaged launch, multi-surface assertion, window waiting, CI needs).

5 / 5

Workflow Clarity

Steps 1–10 form a clear, coherent sequence (install → first test → packaged launch → assertions → config → run → parse → CI) with a failure feedback loop via the trace viewer. It falls short of 5 because inter-step validation is implicit (test assertions themselves) rather than explicit checkpoints, and no verify step follows install or config.

4 / 5

Progressive Disclosure

The SKILL.md acts as a well-organized spine: both bundle files exist, are one level deep, and are signaled inline at the point of need ("Full API table: references/electron-ci-and-api.md", "see the migration shopping list in references/spectron-migration.md"), with the bulk API table, CI workflow, and Spectron history correctly split out of the spine. This matches the clear-overview, one-level-deep-references pattern of the 5 anchor.

5 / 5

Total

17

/

20

Passed

Description

87%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.

A strong description: it opens with an explicit dual trigger (new Electron e2e tests or Spectron migration), then enumerates concrete capabilities covering both main-process and renderer surfaces. Third-person/imperative voice is correct and there is no padding.

DimensionReasoningScore

Specificity

The description lists several concrete, specific actions — "Playwright's _electron.launch, renderer windows as Pages, main-process checks via electronApp.evaluate, and IPC and DOM assertions from one suite" — going well beyond naming the domain. It falls short of the 5 anchor only because coverage has minor gaps (e.g., packaged-binary launching and CI are not surfaced).

4 / 5

Completeness

Both halves are explicit: the what is concrete ("_electron.launch", "renderer windows as Pages", "main-process checks via electronApp.evaluate", "IPC and DOM assertions") and the when is a clear trigger clause ("Use whenever an Electron desktop app needs end-to-end tests, or a Spectron suite must be migrated"). This matches the 5 anchor's pattern of what + when with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural user phrases are present — "Electron desktop app needs end-to-end tests", "a Spectron suite must be migrated" — matching how users would actually phrase the need. A few common variations (e.g., "e2e", "automated tests") are missing, keeping it below the comprehensive 5 anchor.

4 / 5

Distinctiveness Conflict Risk

The Electron/Spectron niche is distinct and the triggers ("Electron desktop app", "Spectron suite") would not fire for unrelated skills; it even implicitly separates itself from generic web-browser Playwright usage. Conflict risk is minimal, matching the 5 anchor's clear-niche description.

5 / 5

Total

18

/

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