daytona-windows-cert

test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed, Windows sandbox, daytona windows, self-hosted cert. Use when validating iPolloWork Windows enterprise TLS/OS-trust fixes in a Daytona Windows sandbox.

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.opencode/skills/daytona-windows-cert/SKILL.md

Quality

Content

81%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 an unusually concrete, executable runbook with genuine validation checkpoints and hard-won Windows-specific gotchas that Claude could not reconstruct on its own. Its weaknesses are redundancy — several command blocks restated verbatim as 'verified session shapes' and the bundle probe script inlined — and limited use of the bundle for content that belongs in reference files.

Suggestions

Delete the three duplicate code blocks introduced by 'The release command shape from the verified session was...', 'The Windows download/extract shape from the verified session was...', and the second 'daytona sandbox start' example; one verified copy of each command is enough.

Reference scripts/ca-probe.js instead of inlining its full 34 lines, keeping only the run command and the expected result JSON in the body.

Move the shell/quoting gotchas section into a references/ file (e.g. references/windows-exec-gotchas.md) with a one-line pointer from the body, so the main workflow stays scannable.

Dimension	Reasoning	Score
Conciseness	Most content is hard-won, non-obvious operational knowledge (the session-0 trap, the EncodedCommand recipe, the memoized system-ca-bundle.pem gotcha) that earns its tokens, but there is real padding: three command blocks are repeated verbatim under 'the shape from the verified session was' prefaces, 'daytona sandbox start' is shown twice in placeholder and variable forms, and the full 34-line ca-probe.js is inlined despite existing as a bundle script. It could be meaningfully tightened without losing anything, which is the anchor-3 profile rather than the efficient anchor-4 one.	3 / 5
Actionability	Every step is copy-paste executable: exact daytona/gh/schtasks commands, a working base64 UTF-16LE EncodedCommand pipeline, real Windows paths, the correct userData directory, and the expected probe output JSON. The only non-executable moment — the zip-staging comment telling the user where to place the build — is explicit and necessary guidance.	5 / 5
Workflow Clarity	The numbered sequence (prereqs, create sandbox, exec vs VNC, stage build, stand up repro, verify, cleanup) has explicit validation checkpoints at each fragile point: netstat listener check, a probe that exits 1 on failure with the verified result to compare against, VNC pass/fail expectations for both the healthy :8443 and broken :9443 chains, and a complete cleanup for the destructive parts (sandbox and temporary prerelease deletion).	5 / 5
Progressive Disclosure	The bundle reference is real and correctly signaled — scripts/ca-probe.js exists and the body's path to it matches — and sections are clearly headed and logically ordered. But the probe script is duplicated inline instead of referenced, and ~30 lines of shell-quoting gotchas would sit better in a reference file; these minor organization gaps keep it below the well-split anchor-5 profile.	4 / 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.

The description has strong, natural trigger coverage and an explicit, specific use-when clause for a well-defined niche. Its main weakness is the near-absence of a 'what' — the first sentence is a bare keyword list and the skill's concrete capabilities are only implied by the when-clause. Broad Windows triggers also create minor overlap risk with sibling daytona skills.

Suggestions

Replace the leading keyword list with a third-person action statement, e.g. 'Install a fake corporate CA into the Windows machine store, serve healthy and broken HTTPS control planes, and verify the iPolloWork desktop app and spawned runtimes use the OS trust path.'

Add the missing natural trigger variants users report, such as 'certificate error', 'SSL cert', and 'trust store', alongside the existing 'TLS fetch failed'.

Narrow the generic Windows triggers (e.g. 'Windows sandbox', 'daytona windows') with a qualifier like 'Windows enterprise-cert testing' to reduce overlap with general Windows/Electron sandbox skills.

Dimension	Reasoning	Score
Specificity	The only stated action is 'validating iPolloWork Windows enterprise TLS/OS-trust fixes'; the concrete capabilities the skill performs (install a fake corporate CA, serve healthy/broken HTTPS control planes, probe the OS trust path) never appear. It names the domain with one concrete action, matching the 1-2-actions anchor rather than the several-specific-actions anchors.	3 / 5
Completeness	An explicit 'Use when validating iPolloWork Windows enterprise TLS/OS-trust fixes in a Daytona Windows sandbox' clause answers both what and when, and the when is specific. It falls short of a 5 because the 'what' is thin: the leading keyword list carries no action statement, so the capability description is not clearly and separately articulated.	4 / 5
Trigger Term Quality	Natural phrases users would actually say are well covered — 'test on Windows', 'enterprise CA', 'corporate certificate', 'GPO cert', 'TLS fetch failed', 'Windows sandbox', 'self-hosted cert' — including the literal error string. Common variants like 'certificate error', 'SSL cert', or 'trust store' are missing, so coverage is good rather than comprehensive.	4 / 5
Distinctiveness Conflict Risk	The niche is clear (iPolloWork + Daytona Windows + enterprise CA), but broad triggers like 'test on Windows', 'Windows sandbox', and 'daytona windows' would also fire for general Windows-sandbox or Electron-testing skills, and the description draws no boundary against them. Minor overlap risk with closely related skills, not the minimal-conflict profile of a 5.	4 / 5
	Total	15 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 5 missing, 5 deeper-than-1-level	Warning

	Total	15 / 16 Passed

Repository: Devin-AXIS/iPolloWork
Path: .opencode/skills/daytona-windows-cert/SKILL.md
Commit: dada31d

Reviewed: 12 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.