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.

63

Quality

74%

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

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

A tight, command-driven skill body: real scripts with arguments, health-check endpoints, log-inspection commands, and a sensible start-to-evidence flow with a validation checkpoint. The only real improvements are defining the $SERVER_SANDBOX variable, adding a re-validate step after log inspection, and trimming the small redundancy between the two-sandbox sections. Structure and disclosure are appropriate for a skill of this size.

DimensionReasoningScore

Conciseness

The body is lean — commands, ports, and scripts with almost no concept explanation — e.g. 'The helper creates a separate server sandbox, starts MySQL, Den API, Den Web, and worker proxy, waits for health checks, then prints URLs.' Minor trimming is possible: 'When To Use Two Sandboxes' repeats the two-sandbox rationale already given in 'Connect Electron To Server', keeping it just below the every-token-earns-its-place anchor at 5.

4 / 5

Actionability

Commands are concrete and near copy-paste ready: 'bash .devcontainer/test-server-on-daytona.sh [branch-or-commit]', 'curl -sf <DEN_WEB_URL>/api/den/health', and daytona exec log tails. Minor gaps remain — the placeholders <DEN_WEB_URL>/<DEN_API_URL> rely on the helper's printed output, and $SERVER_SANDBOX is used but never defined — so it does not fully meet the 'specific examples cover the common cases' bar of 5.

4 / 5

Workflow Clarity

The sequence is clear and ordered — start the server sandbox, health-check with curl, connect the Electron sandbox with the printed URLs, gather evidence — and includes explicit validation plus an error-recovery branch: 'Inspect logs if health checks fail' with tail commands. It stops short of the anchor-5 feedback loop because no re-check/fix-retry step is stated after log inspection, and the ordering is implied by section order rather than an explicit numbered flow.

4 / 5

Progressive Disclosure

There are no bundle files and none are needed — the body is short, fully self-contained, and organized into well-labeled sections ('What This Covers', 'Start Server Sandbox', 'Connect Electron To Server', 'Validate Server Health', 'When To Use Two Sandboxes', 'Evidence'). Per the simple-skill guidance, well-organized sections with no need for external references warrant a 5; the cross-references to sibling skills (daytona-electron-den, daytona-recording-artifacts) are clearly signaled and one level deep.

5 / 5

Total

17

/

20

Passed

Description

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

A dense, domain-specific description with an explicit use-when clause and strong niche distinctiveness. Its main weaknesses are noun-list phrasing that never states what the skill actually does with those components, and a 'when' clause that undersells the full scope. It is clearly distinguishable from generic skills and would trigger correctly for its intended audience.

Suggestions

Convert the component noun list into verb-led capabilities, e.g. 'Starts the Daytona server sandbox (Den web/API, worker proxy, MySQL), validates health, and wires the Electron client to it.'

Broaden the 'when' clause to match the skill's real scope: 'Use for server-side setup, marketplace/org-policy/cloud-auth flows, or desktop-plus-cloud end-to-end validation.'

Drop or sharpen the Electron wording (e.g. 'server side of desktop-plus-cloud e2e') so it does not compete with the sibling daytona-electron-den skill for desktop-side triggers.

DimensionReasoningScore

Specificity

The description names concrete domain items — 'marketplace server, worker proxy, cloud auth, org policies, connect Electron to Den' — but presents them as noun phrases rather than actions; only 'connect Electron to Den' reads as a verb-led capability. This matches the anchor 'names domain and 1-2 concrete actions, but not comprehensive' better than 4, which expects several specific actions.

3 / 5

Completeness

Both parts are present: a 'what' via the component list and an explicit 'when' via 'Use for server-side setup in validated flows.' The 'when' clause is terse and narrower than the skill's actual scope (the body also covers marketplace, org-policy, and two-sandbox e2e flows), fitting 'both present; when could be more explicit or specific' rather than the fully concrete anchor at 5.

4 / 5

Trigger Term Quality

Terms like 'Daytona', 'Den sandbox', 'worker proxy', 'cloud auth', 'org policies', and 'Electron' are exactly what a user on this project would say, giving good keyword coverage. A few natural variations ('hosted', 'server sandbox', 'preview URLs', 'end-to-end' spelled out) are missing, so it falls short of the comprehensive-synonym anchor at 5.

4 / 5

Distinctiveness Conflict Risk

The niche is clear — Daytona-hosted server components for this specific project — with minimal conflict against generic skills. However, 'desktop plus cloud e2e' and 'connect Electron to Den' overlap the territory of the sibling 'daytona-electron-den' skill referenced in the body, matching 'mostly distinct; minor overlap risk with closely related skills' rather than 5.

4 / 5

Total

15

/

20

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.

Validation — 16 / 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.