CtrlK
BlogDocsLog inGet started
Tessl Logo

daytona-electron-test

do e2e tests, run e2e, test on Daytona, run Electron on Daytona, validate feature, real desktop flow, CDP/noVNC, PR proof. Launch and drive OpenWork Electron in Daytona with validated frame evidence.

56

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./.opencode/skills/daytona-electron-test/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The content is highly actionable with comprehensive executable commands and well-checkpointed individual workflows, but it is held back by repeated helper snippets, overlap with sibling skills, and a monolithic structure with no bundle files offloading reference material. Splitting the selector map and Den/recording sections into referenced files would materially improve it.

Suggestions

Extract the UI automation selector map and the repeated click/paste helper IIFEs into a references file (e.g. references/ui-helpers.md) and reference it once, eliminating the ~6 near-duplicate snippets.

Move the two-sandbox Den + Electron marketplace eval and the window-management section into referenced files or the owning sibling skill, keeping only a one-line pointer here.

Add a single top-to-bottom quickstart checklist that chains sandbox start -> CDP connect -> real-Electron verify -> drive flow -> capture evidence -> teardown, with a validation gate before `daytona delete`.

DimensionReasoningScore

Conciseness

Mostly high-signal (commands, troubleshooting, selector table) but noticeably padded: the same button-click helper IIFE appears ~6 times near-verbatim across sections, and the two-sandbox Den eval / window-management material overlaps sibling skills and could be trimmed.

3 / 5

Actionability

Nearly everything is copy-paste ready — exact bash commands, complete JS IIFE snippets, a selector table with stable selectors and source files, and a full vitest invocation with env vars — covering all common cases (workspace creation, session, settings, provider connect, before/after recording).

5 / 5

Workflow Clarity

The main flows ('Fastest path', 'Creating a workspace', before/after recording) have clear sequences with explicit validation checkpoints (URL pattern, 'OpenWork Ready', opencode process check, 'Must contain Electron/'); minor gaps keep it below 5 — no single end-to-end checklist and the teardown lacks pre-delete validation.

4 / 5

Progressive Disclosure

No bundle files exist, so the ~600-line body is a monolith with section headers but significant inlined reference material (full selector map, two-sandbox Den eval the doc itself flags as belonging elsewhere, recording workflow) that should be split into separate files.

3 / 5

Total

15

/

20

Passed

Description

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

The description conveys a clear, niche capability with strong natural trigger terms, but it omits an explicit 'Use when...' clause and front-loads redundant keyword fragments that dilute specificity. Tightening the keyword dump into a single trigger clause would lift completeness and specificity.

Suggestions

Replace the leading keyword dump with an explicit 'Use when...' clause (e.g., 'Use when the user asks to run e2e tests, test on Daytona, or reproduce a bug in the real Electron app').

Drop the redundant 'do e2e tests, run e2e' pair and keep one natural trigger phrase to reduce fluff.

Lead with the concrete action sentence ('Launch and drive OpenWork Electron in Daytona with validated frame evidence') before the trigger clause for stronger specificity.

DimensionReasoningScore

Specificity

Names the domain and a couple concrete actions ('Launch and drive OpenWork Electron in Daytona with validated frame evidence'), but the first half is a redundant keyword dump ('do e2e tests, run e2e, validate feature') rather than several distinct actions.

3 / 5

Completeness

Has a clear 'what' but no explicit 'Use when...' trigger clause; the 'when' is only weakly implied via keyword fragments, so per the missing-trigger cap it stays at 3.

3 / 5

Trigger Term Quality

Good coverage of natural phrasings a user would say ('test on Daytona', 'run e2e', 'validate feature', 'PR proof'); not a 5 due to keyword redundancy ('do e2e tests'/'run e2e') and some jargon ('CDP/noVNC').

4 / 5

Distinctiveness Conflict Risk

The 'OpenWork Electron in Daytona' + CDP/noVNC niche is mostly distinct, with only minor overlap risk against the sibling daytona-* skill family.

4 / 5

Total

14

/

20

Passed

Validation

87%

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

Validation14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (607 lines); consider splitting into references/ and linking

Warning

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

14

/

16

Passed

Repository
different-ai/openwork
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.