CtrlK
BlogDocsLog inGet started
Tessl Logo

daytona-cloud-server

Daytona cloud server, Den sandbox, desktop plus cloud e2e, marketplace server, worker proxy, cloud auth, org policies, connect Electron to Den. Use for server-side setup in validated flows.

65

Quality

77%

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

Fix and improve this skill with Tessl

tessl review fix ./.opencode/skills/daytona-cloud-server/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

87%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a lean, highly actionable overview with concrete commands, clear validation, and well-signaled cross-references. The main gap is that the health-check error-recovery loop is not fully closed (it diagnoses via logs but does not explicitly fix and re-validate).

Suggestions

Close the validation feedback loop: after "Inspect logs if health checks fail," add an explicit fix-then-re-run step (e.g. "fix the failing service, restart it, then re-run the health checks before proceeding").

Convert the multi-sandbox flow into a short numbered checklist (start server sandbox → connect Electron → validate health → capture evidence) so the sequence and checkpoints are unambiguous.

Optionally state what success looks like for each validation command (expected HTTP status / log line) so failure is unambiguous.

DimensionReasoningScore

Conciseness

The body is lean with tight code blocks and bullet lists, explains no concepts Claude already knows, and its prose is orientation and cross-skill caveats (e.g. "Server health alone does not prove Electron cloud behavior works") that earn their place rather than padding.

3 / 3

Actionability

It provides concrete, executable commands with real flags and paths (bash .devcontainer/test-server-on-daytona.sh, curl -sf <DEN_WEB_URL>/api/den/health, daytona exec ... 'tail -120 /tmp/den-api.log'), which are copy-paste ready once placeholders are filled.

3 / 3

Workflow Clarity

The sectioned sequence is clear and health-check validation is explicit, but the error-recovery loop stops at "Inspect logs if health checks fail" without an explicit fix-and-re-validate closure, and there is no numbered checklist for the multi-sandbox flow, leaving checkpoints present but the feedback loop incomplete.

2 / 3

Progressive Disclosure

Content is organized into clearheaded sections with well-signaled, one-level-deep references to sibling skills and repo scripts ("use the daytona-electron-den skill", "Pair this with the daytona-recording-artifacts skill"), with no nested references and an appropriately self-contained overview.

3 / 3

Total

11

/

12

Passed

Description

67%

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 covers a clear, specific niche and includes an explicit "Use for..." trigger, but it reads as a jargon-heavy noun inventory rather than a list of concrete actions, and it bleeds into sibling skill territory. Tightening into action verbs and more natural trigger phrasing would raise specificity and trigger-term quality.

Suggestions

Rewrite the noun inventory as concrete actions, e.g. "Starts the hosted Daytona server sandbox, runs MySQL/Den API/Den Web/worker proxy, and wires Electron to the printed server URLs."

Add natural trigger phrasing users would say, e.g. "Use when setting up or validating the iPolloWork cloud server on Daytona," instead of the jargon "in validated flows."

Sharpen the boundary with sibling skills by stating what this skill does NOT cover (e.g. the Electron desktop side lives in daytona-electron-den) to reduce conflict risk.

DimensionReasoningScore

Specificity

It names the domain and a couple actions ("server-side setup", "connect Electron to Den") but is largely a comma-separated noun inventory ("marketplace server, worker proxy, cloud auth, org policies") rather than a comprehensive list of concrete actions, so it sits above the vague level but below the multi-action ideal.

2 / 3

Completeness

It explicitly answers what (the component list) and when ("Use for server-side setup in validated flows") with an explicit trigger clause, which is stronger than the score-2 anchor whose "when" is missing or only implied.

3 / 3

Trigger Term Quality

Relevant domain keywords appear (Daytona, Den, marketplace, cloud auth, worker proxy) but the phrasing is jargon-heavy ("e2e", "validated flows") and misses the natural, plain-language variations a user would actually say, fitting "some relevant keywords but missing common variations."

2 / 3

Distinctiveness Conflict Risk

It targets a specific niche but explicitly mentions "connect Electron to Den" and "desktop plus cloud e2e," which overlap with sibling daytona-* skills (notably daytona-electron-den), so it could still trigger for the wrong sibling skill.

2 / 3

Total

9

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
Devin-AXIS/iPolloWork
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.