daytona-flow-validator

do e2e tests, validate feature, prove it works, pass/fail, frame proof, screenshots, CDP assertions. Daytona validation loop for real app behavior with repair before declaring success.

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Medium

Suggest reviewing before use

Fix and improve this skill with Tessl

tessl review fix ./.opencode/skills/daytona-flow-validator/SKILL.md

Quality

Content

77%

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 workflow-clear with strong validation feedback loops, but it is a long monolithic file with some repeated imperative rules and no progressive disclosure to reference files.

Suggestions

Move the large Linux Desktop Automation xdotool/wmctrl patterns and the Lexical Composer paste snippet into reference files (e.g. references/desktop-automation.md, references/composer-paste.md) and link to them from the body to improve progressive disclosure.

Consolidate the repeated "observe before/after, never trust a screenshot alone" rule into one authoritative statement and reference it instead of restating it in Screenshots and Repair Loop.

Trim restated imperative preaching in the Screenshots section (the inspect-before-sharing rule is explained twice) to recover token budget.

Dimension	Reasoning	Score
Conciseness	Almost all content is task-specific operational detail Claude would not already know, but the same governing principle (observe before/after, never claim success from a screenshot alone) is restated across Core Rule, Screenshots, and Repair Loop, so it could be tightened.	2 / 3
Actionability	It provides fully executable, copy-paste-ready guidance: `daytona exec` bash commands, a synthetic-paste JS function, `browser_*` tool calls, and concrete wmctrl/xdotool patterns.	3 / 3
Workflow Clarity	Multi-step processes are explicitly sequenced with validation checkpoints: the 5-step Core Rule loop, the 5-step Repair Loop, the Validation Loop Template, and explicit Passed/Failed/Incomplete verdict definitions.	3 / 3
Progressive Disclosure	The body is well-sectioned by headings but is a ~244-line monolithic file with no bundle reference files; large sub-procedures (xdotool patterns, composer paste, screenshot checks) that could live in separate references are inline.	2 / 3
	Total	10 / 12 Passed

Description

57%

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 conveys a clear, distinctive niche and lists real actions, but its telegraphic comma-spliced style, jargon-heavy trigger terms, and total absence of an explicit "Use when" clause hold it to mid-range scores.

Suggestions

Rewrite as a clean declarative sentence (third person) listing concrete actions, e.g. "Runs end-to-end Daytona Electron and browser flow validation using CDP: captures screenshots, asserts observable state, and repairs before declaring a pass/fail verdict."

Add an explicit trigger clause such as "Use when the user asks to test, validate, or prove a Daytona app flow works end-to-end."

Replace jargon-only triggers ("frame proof", "CDP assertions") with natural phrasings a user would actually say ("prove my app flow works", "capture evidence the feature works").

Dimension	Reasoning	Score
Specificity	It names the domain and several concrete actions ("e2e tests", "CDP assertions", "screenshots", "validation loop"), but the comma-spliced run-on also carries vague telegraphic phrases like "prove it works" and "frame proof", so it is not a clean comprehensive action list.	2 / 3
Completeness	The description answers "what" (validate flows, capture proof) but provides no "Use when..." clause or equivalent explicit trigger guidance, so per the judging guidelines completeness is capped at 2.	2 / 3
Trigger Term Quality	Some relevant natural terms appear ("e2e tests", "validate", "screenshots", "pass/fail"), but the description leans heavily on technical jargon ("CDP assertions", "Daytona validation loop", "frame proof") and misses common user phrasings like "test my app" or "does this flow work".	2 / 3
Distinctiveness Conflict Risk	The Daytona + CDP + Electron/browser validation niche is specific and unlikely to trigger for unrelated skills, matching the clear-niche anchor.	3 / 3
	Total	9 / 12 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-flow-validator/SKILL.md
Commit: 1345d51

Reviewed: about 13 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.