daytona

Daytona CLI setup, sandbox debugging, keep a sandbox alive, secrets volume, snapshot refresh. Use when Daytona itself is the problem, not for running tests (see run-tests).

Quality

77%

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/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 lean and highly actionable with copy-paste-ready commands and clean sectioning. Its main weakness is the absence of validation/verification checkpoints for destructive operations like sandbox deletion and snapshot refresh.

Suggestions

Add a verification step before 'daytona delete <sandbox>' (e.g. confirm the sandbox name, check it is not a long-lived one) to satisfy the destructive-operation validation requirement.

Add a post-creation check for the snapshot refresh commands (e.g. 'daytona snapshot list' to confirm the new snapshot exists) as a validation checkpoint.

Trim the justification clauses in the sandbox sections to one-line imperatives to push conciseness toward the top anchor.

Dimension	Reasoning	Score
Conciseness	Lean, mostly assumes Claude's competence with tight executable sections and no concept over-explanation; a few justification clauses (e.g. 'Keep that sandbox for exploration or debugging instead of reproducing its provisioning commands') are mild over-explanation short of a pristine 5.	4 / 5
Actionability	Fully executable, copy-paste-ready commands throughout — 'brew install daytonaio/cli/daytona', 'daytona login', 'pnpm evals:e2e <slug>', 'daytona preview-url <sandbox> -p 9825', 'daytona delete <sandbox>' — covering the common cases.	5 / 5
Workflow Clarity	Tasks are clearly sectioned, but destructive operations ('daytona delete <sandbox>', snapshot refresh that overwrites) lack any validation or verification checkpoint, so workflow clarity is capped at 3 per the destructive-operations rule.	3 / 5
Progressive Disclosure	Well-organized into clear sections with no bundle files to reference and content appropriately inline; slightly above the under-50-lines threshold and without one-level-deep references, so it sits above the 3-anchor but short of an ideal 5.	4 / 5
	Total	16 / 20 Passed

Description

78%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 specific, third-person, and clearly states both capabilities and a concrete use trigger with a helpful negative boundary. It is strong overall, with minor room to broaden trigger synonyms to reach the top anchor.

Dimension	Reasoning	Score
Specificity	Names the Daytona domain with several concrete actions — 'CLI setup', 'sandbox debugging', 'keep a sandbox alive', 'secrets volume', 'snapshot refresh' — covering capabilities comprehensively, though 'sandbox debugging' is slightly generic compared to the fully enumerated 5-anchor.	4 / 5
Completeness	Explicitly answers both 'what' (capability list) and 'when' ('Use when Daytona itself is the problem, not for running tests'), with the 'when' concrete and including a negative boundary, though trigger breadth falls short of the fully enumerated 5-anchor.	4 / 5
Trigger Term Quality	Includes natural terms a user would say ('Daytona', 'sandbox', 'secrets volume', 'snapshot') with good coverage, but lacks synonyms and file extensions found in the 5-anchor.	4 / 5
Distinctiveness Conflict Risk	Clear Daytona-specific niche with an explicit negative boundary ('not for running tests (see run-tests)') that distinguishes it from the run-tests skill, giving minimal conflict risk.	5 / 5
	Total	17 / 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: different-ai/openwork
Path: .opencode/skills/daytona/SKILL.md
Commit: 9f0e880

Reviewed: 3 days 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.