daytona-dev

Daytona development environment overview. Use when the user asks about Daytona setup, Daytona toolbox, dev environment, noVNC, CDP, server sandbox, secrets volume, Electron sandbox, standalone Chrome, validation, or artifacts volume.

Quality

70%

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-dev/SKILL.md

Quality

Content

76%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 body is highly actionable and reasonably token-efficient, with executable commands for setup, operation, and troubleshooting. Its main weaknesses are workflow clarity — implicit validation checkpoints, a numbering gap, and a vague Option B — and mild redundancy in the two overlapping skill lists.

Suggestions

Add explicit validation checkpoints to the workflow, e.g. after the helper runs: verify the printed noVNC URL responds and `curl -s http://127.0.0.1:9825/json/list` shows an Electron target before interacting.

Fix the Quick Start numbering (sections jump from 2 to 4) and make Option B concrete or link to a reference for the SSH tunnel command.

Merge the redundant "four reusable pieces" and "Focused skills" lists into one clearly-signaled section, or move them to a separate reference file to slim the main body.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean — commands, a service table, and terse troubleshooting — but the two overlapping skill lists ("four reusable pieces" and "Focused skills") are redundant, and filler like "Open that URL in your browser. You'll see the real Electron iPolloWork app" could be trimmed. Anchor 4 (efficient with minor over-explanation), not 5.	4 / 5
Actionability	Copy-paste-ready bash commands throughout: sandbox creation via a helper script, `daytona preview-url` for each port, log tails, screenshot capture, restart, stop/start/delete, plus executable fixes in Troubleshooting. Specific examples cover the common cases, matching anchor 5.	5 / 5
Workflow Clarity	A sequence is present (create sandbox → get noVNC URL → open it) and Troubleshooting aids recovery, but validation checkpoints are implicit (no verify-the-app-is-running step before opening the URL), the Quick Start numbering skips "### 3", and Option B ("tunnel to the sandbox") is vague. Fits anchor 3 (sequence present, checkpoints missing or implicit), not 4.	3 / 5
Progressive Disclosure	No bundle files exist; the skill is a single well-sectioned document (Prerequisites, Quick Start, What's Running, Common Commands, Troubleshooting) with clearly named external skills and scripts. Good structure with minor gaps — the redundant skill lists and ~165 lines of mixed overview plus operations detail could be split. Anchor 4, not 5.	4 / 5
	Total	16 / 20 Passed

Description

65%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 has strong, explicit trigger guidance and a distinctive Daytona-specific niche, but the capability statement is under-specified — "overview" tells Claude nothing actionable about what the skill does. Replacing it with the concrete actions from the body (launching the Electron app in a Daytona sandbox, exposing noVNC/CDP URLs) would lift both specificity and completeness.

Suggestions

Replace "Daytona development environment overview" with concrete actions, e.g. "Launch the iPolloWork Electron app in a Daytona cloud sandbox and access it via noVNC/CDP preview URLs."

Trim overly broad trigger terms like "validation" that could fire for unrelated validation tasks, and add natural synonyms such as "cloud sandbox" or "remote dev environment".

State the 'what' and 'when' with equal concreteness so the capability half matches the quality of the trigger half.

Dimension	Reasoning	Score
Specificity	The description names the domain ("Daytona development environment overview") but states no concrete actions — "overview" is generic, unlike the body's "Launch the iPolloWork Electron app". It matches the anchor 'Names the domain but actions are minimal or generic', not level 3 which requires 1-2 concrete actions.	2 / 5
Completeness	Has an explicit "Use when the user asks about..." clause with concrete triggers, but the 'what' half ("Daytona development environment overview") is vague. It fits anchor 4 (both present, 'what' could be more specific), not 5 which requires both to be concretely explicit.	4 / 5
Trigger Term Quality	Good keyword coverage: "Daytona setup", "noVNC", "CDP", "secrets volume", "Electron sandbox", "standalone Chrome", "artifacts volume" are terms a user would naturally say. Not level 5 because common synonyms and variations (e.g. "cloud sandbox", "remote dev environment") are missing.	4 / 5
Distinctiveness Conflict Risk	"Daytona" plus specific features (noVNC, CDP, secrets volume) carves a clear niche, but broad trigger terms like "dev environment" and "validation" create minor overlap risk with general development or validation skills. Anchor 4, not 5.	4 / 5
	Total	14 / 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-dev/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.