daytona-electron-den

Electron and Den, desktop plus cloud, two-sandbox e2e, cloud auth, marketplace, org policy, worker proxy, provider sync, desktop handoff. Validate Electron against a Daytona Den server with unified proof.

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.opencode/skills/daytona-electron-den/SKILL.md

Quality

Content

82%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 a lean, highly actionable operational runbook with concrete commands, expected values, and explicit validation checkpoints for each phase. Its main weaknesses are a minor variable inconsistency (SANDBOX vs SERVER_SANDBOX), a missing error-recovery loop for failed validations, and no external reference structure for the deeper material it alludes to.

Suggestions

Fix the variable inconsistency: the server step records SERVER_SANDBOX but the bootstrap step runs 'daytona exec "$SANDBOX"', leaving a copy-paste command with an undefined variable.

Add brief error-recovery guidance (e.g. what to check and how to retry when a Den health check fails or the bootstrap file shows production URLs instead of the Daytona values).

Note how the CDP JavaScript snippet should be executed (e.g. via Electron's remote debugging CDP evaluate), since the snippet alone is not runnable without that context.

Dimension	Reasoning	Score
Conciseness	The body is entirely command- and assertion-driven ('bash .devcontainer/test-on-daytona.sh <branch-or-commit> --den-base-url ...', 'curl -sf "$DEN_WEB_URL/api/den/health"') with zero explanation of concepts Claude already knows; every section earns its tokens, matching the lean-and-efficient anchor.	5 / 5
Actionability	Guidance is almost fully executable — copy-paste bash commands with flags, an exact bootstrap file path, and expected values ('baseUrl is DEN_WEB_URL ... not production'). It falls short of 5 because 'daytona exec "$SANDBOX"' references a variable never defined (the recorded value is SERVER_SANDBOX), and the CDP JavaScript snippet is given without any indication of how to execute it.	4 / 5
Workflow Clarity	The sequence is clear (server sandbox → health validation → Electron launch → bootstrap validation → handoff → per-feature loop → evidence) with explicit checkpoints (curl health checks, expected baseUrl/apiBaseUrl values, a minimum-assertion checklist). It is not 5 because no error-recovery feedback loop is given for when a health or bootstrap check fails.	4 / 5
Progressive Disclosure	Sections are well-organized, all content is appropriately inlined for a single operational workflow, and there are no nested or buried references. It does not reach 5 because the body exceeds the simple-skill threshold (~95 lines), the referenced 'server skill' dependency is only loosely signaled, and no bundle structure exists to verify or navigate.	4 / 5
	Total	17 / 20 Passed

Description

62%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 is highly specific and distinctive for its narrow domain, clearly stating what the skill validates, but it completely lacks a 'when to use' trigger clause, capping its completeness and natural trigger-term coverage. Rewriting the feature-topic list as verb-first actions with an explicit 'Use when...' clause would move it to the top band.

Suggestions

Add an explicit trigger clause, e.g. 'Use when validating Electron cloud behavior (auth, marketplace, org policy, provider sync, worker proxy) against a Daytona Den server.'

Convert the noun-phrase topic list into concrete verb-first actions (e.g. 'Validates cloud auth handoff, marketplace installs, org policy enforcement, provider sync, and worker proxy recovery').

Include a few natural variations users would actually say, such as 'e2e', 'end-to-end', 'cloud tests', or 'Daytona sandbox', to improve trigger-term coverage.

Dimension	Reasoning	Score
Specificity	Concrete feature areas are enumerated ('cloud auth, marketplace, org policy, worker proxy, provider sync, desktop handoff') plus a specific action ('Validate Electron against a Daytona Den server'), but the feature list is noun-phrase topics rather than multiple concrete actions, so it sits between anchors 4 and 5 — closer to 4.	4 / 5
Completeness	The 'what' is clear ('Validate Electron against a Daytona Den server with unified proof') but no 'when' clause or equivalent trigger guidance exists anywhere in the description, which caps completeness at 3 per the judging guidelines.	3 / 5
Trigger Term Quality	Terms like 'Electron', 'Den', 'Daytona', 'marketplace', 'e2e' are relevant domain keywords, but natural user phrasings and common variations/synonyms are missing, matching anchor 3; it is not score 4 because there is no natural 'use when'-style trigger vocabulary.	3 / 5
Distinctiveness Conflict Risk	The description names a highly niche, tool-specific workflow ('Daytona Den server', two-sandbox Electron/Den e2e) with distinct triggers and essentially zero overlap risk with generic skills.	5 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

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.

Repository: Devin-AXIS/iPolloWork
Path: .opencode/skills/daytona-electron-den/SKILL.md
Commit: dada31d

Reviewed: 12 hours ago

Table of Contents

Discovery Implementation Validation

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.