fraimz

create a fraimz, make fraimz, prove it works, frame proof, PR proof, validate experience, e2e evidence, fraimz.html. The full fraimz loop — frame the claim, drive the real app via CDP, validate/repair, output fraimz.html. Use whenever a task ends with "please create a fraimz" or any change needs end-to-end proof.

Quality

82%

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

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 a well-structured, actionable guide with a clear multi-step workflow and an explicit validate-repair-repeat feedback loop. It assumes Claude's competence and avoids over-explaining known concepts; the main gap is that some inline material (helper catalog, pitfalls) could be moved into reference files for cleaner progressive disclosure.

Suggestions

Move the full `ctx.* helpers` catalog into a reference file and keep only `ctx.prove` and 2–3 most-used helpers inline with a pointer, to sharpen progressive disclosure.

Add a single concrete minimal flow snippet under "Code the flow" so the headline API is shown end-to-end rather than only described and deferred to existing flows.

Consider splitting "Pitfalls (learned the hard way)" into a separate reference; the section is valuable but is the largest inline block and pushes the body past overview length.

Dimension	Reasoning	Score
Conciseness	The body is dense but lean — it does not explain what CDP, Electron, or a flow file is, and every section earns its place. A few spots (the repeated loop framing across "Every fraimz is a demo", "Voiceover first", and "The loop") could be tightened, keeping it just below a 5.	4 / 5
Actionability	Concrete copy-paste commands (`pnpm fraimz scaffold <flow-id>`, `IPOLLOWORK_ELECTRON_REMOTE_DEBUG_PORT=9826 pnpm dev`, `bash .devcontainer/test-on-daytona.sh`) and a precise `ctx.prove("claim", { voiceover, action, assert, screenshot })` API are given, but the "Code the flow" step is described abstractly and defers full examples to referenced files, so minor gaps remain.	4 / 5
Workflow Clarity	"The loop" lays out a clear six-step sequence (Frame → Get script → Code flow → Drive → Validate/repair → Verdict) with an explicit feedback loop ("fix the visible state or the code and rerun until every claim has a passing assertion") and a clear pass/fail verdict checkpoint, matching the anchor for explicit validation with error-recovery loops.	5 / 5
Progressive Disclosure	Well-organized sections with a dedicated "Source of truth" list pointing one level deep to evals/README.md, evals/flows/, and the daytona-* skills; no bundle files exist so content lives entirely in SKILL.md. It scores 4 rather than 5 because sizable inline material (the ctx.* helper catalog and the pitfalls list) could be split into reference files, and the inlined helper API is not clearly signaled as the place for full reference.	4 / 5
	Total	17 / 20 Passed

Description

83%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 clearly states both what the skill does and when to invoke it, with concrete actions and natural trigger phrases. Its main weakness is a stuffed, repetitive keyword prefix that pads rather than informs, and a broad e2e-proof trigger that risks overlap with general testing skills.

Suggestions

Trim the redundant leading keyword run ("create a fraimz, make fraimz, prove it works, frame proof, PR proof, validate experience, e2e evidence, fraimz.html") to the two or three most natural trigger phrases; the rest adds padding without distinctiveness.

Narrow the "when" clause beyond "any change needs end-to-end proof" to reduce overlap with generic e2e/testing skills — e.g. tie it explicitly to the fraimz.html artifact and the CDP-driven demo loop.

Keep the third-person voice consistent; the current phrasing is mostly fine but ensure no second-person framing creeps in around the trigger guidance.

Dimension	Reasoning	Score
Specificity	Lists several concrete actions — "frame the claim, drive the real app via CDP, validate/repair, output fraimz.html" — but the leading "create a fraimz, make fraimz, prove it works" is redundant stuffing rather than additional distinct capabilities, so it sits just below the comprehensive 5.	4 / 5
Completeness	Explicitly answers both what ("The full fraimz loop — frame the claim, drive the real app via CDP, validate/repair, output fraimz.html") and when ("Use whenever a task ends with 'please create a fraimz' or any change needs end-to-end proof") with concrete trigger phrases.	5 / 5
Trigger Term Quality	Good coverage of natural trigger phrases ("please create a fraimz", "prove it works", "e2e evidence", "end-to-end proof", "PR proof") with synonyms, but the coined term "fraimz" limits how naturally users would say several of them, keeping it just short of a 5.	4 / 5
Distinctiveness Conflict Risk	The coined "fraimz" name and the specific CDP-driven HTML artifact give it a clear niche, but "any change needs end-to-end proof" / "e2e evidence" is broad enough to overlap with general testing and e2e skills, so minor overlap risk remains.	4 / 5
	Total	17 / 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/fraimz/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.