run-evals

do e2e tests, run e2e, validate feature, prove it works, PR proof, frame proof, pnpm evals. Launches iPolloWork on Daytona or local Electron and runs the coded eval flows via CDP. Launch + run mechanics; the proof loop itself is the fraimz skill.

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

Quality

Content

88%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 a tight, highly actionable runbook: concrete commands for the Daytona, local-fallback, and recording paths, with explicit validation checkpoints and feedback loops for error recovery. It loses only minor points for slight redundancy and a couple of under-signaled external references.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence — no explanations of CDP/Electron/what-an-eval-is — but carries minor redundancy (the fraimz boundary restated from the frontmatter, and the "local run is not a Daytona validation" aside), keeping it just below the every-token-earns-its-place anchor 5.	4 / 5
Actionability	It provides fully executable, specific commands for the common cases — `bash .devcontainer/test-on-daytona.sh <branch> --artifacts-volume`, `pnpm evals --flow <flow-id> --cdp-url <url>`, the local-fallback `pnnpm dev` block, and `daytona delete "$SANDBOX"` — copy-paste ready with legitimate parameter placeholders.	5 / 5
Workflow Clarity	The launch→verify→run→report→teardown sequence carries explicit validation ("Verify the endpoint before running flows" with the `browser_list` iPolloWork-target check and the DevTools-listening success marker) and feedback loops ("If it fails, inspect /tmp/electron.log"; "If the app shows the Welcome page, create a workspace first"), matching the anchor 5 with error-recovery guidance.	5 / 5
Progressive Disclosure	The SKILL.md is a well-organized overview with one-level-deep, clearly signaled references (the fraimz skill, evals/README.md, evals/daytona-flows.md), but the terse "Details: daytona-recording-artifacts" pointer and the inlined Welcome-page workspace steps are minor organization gaps short of anchor 5.	4 / 5
	Total	18 / 20 Passed

Description

66%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 states concrete launch+run capabilities and includes a useful set of natural trigger terms, but it omits an explicit "Use when..." clause, capping its completeness. Distinctiveness is good thanks to the explicit fraimz boundary, though that same boundary hints at residual overlap risk.

Suggestions

Add an explicit trigger clause such as "Use when the user asks to run e2e tests, validate a feature, or produce PR/frame proof for iPolloWork."

Broaden the action coverage beyond launch+run (e.g., mention writing report artifacts, recording, teardown) to push specificity toward comprehensive.

Replace the jargon-heavy leading keyword dump with a few plain synonyms users actually say (e.g., "end-to-end tests", "regression checks").

Dimension	Reasoning	Score
Specificity	Names the domain and several concrete actions — "Launches iPolloWork on Daytona or local Electron and runs the coded eval flows via CDP" — but coverage stops at launch+run, omitting teardown/recording/results, so it falls short of the comprehensive anchor 5.	4 / 5
Completeness	The "what" is clear (launch + run coded eval flows via CDP on Daytona/local Electron) but there is no explicit "Use when..." clause — only a keyword-dump that weakly implies triggers, so per the missing-trigger-guidance cap it cannot exceed 3.	3 / 5
Trigger Term Quality	Leading phrase list ("do e2e tests, run e2e, validate feature, prove it works, PR proof, pnpm evals") gives good natural-keyword coverage with synonyms, but mixes in project jargon ("frame proof", "fraimz") and misses a few common variations, landing below the comprehensive anchor 5.	4 / 5
Distinctiveness Conflict Risk	It carves a clear niche (iPolloWork e2e via Daytona/local Electron + CDP) and explicitly bounds the sibling "fraimz" skill, but the acknowledged boundary with fraimz signals minor overlap risk, keeping it just below anchor 5.	4 / 5
	Total	15 / 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/run-evals/SKILL.md
Commit: 52934c1

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