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 content is an excellent, tight operational guide: a clearly sequenced loop with explicit validation/repair checkpoints, copy-paste commands, and hard-won pitfalls that only project experience could supply. The main gaps are the absence of an inline minimal ctx.prove flow example, a few rhetorical flourishes that could be trimmed, and references that point to repo files rather than skill-bundle files.

Suggestions

Inline a minimal 3-4 line ctx.prove flow example (claim, voiceover, action, assert, screenshot) so the headline API is executable without opening evals/flows/.

Trim rhetorical flourishes (e.g. "It is the thing a human looks at (and listens to)...", "Pitfalls (learned the hard way)", "you have not framed the experience yet") to tighten token efficiency.

Move the ctx.* helper reference and flow patterns into skill-local files under references/ so the skill remains self-contained if the repo layout changes.

Dimension	Reasoning	Score
Conciseness	The body is dense with project-specific facts Claude cannot know (CDP ports, __ipolloworkControl readiness, voiceover drift checks) and wastes no space on concepts Claude already knows. It falls short of a 5 due to rhetorical flourish ("It is the thing a human looks at (and listens to) to understand, at a glance...", "Pitfalls (learned the hard way)", "If you cannot say which of the two your fraimz is, you have not framed the experience yet") that could be trimmed without losing information.	4 / 5
Actionability	Concrete, executable commands appear throughout: 'IPOLLOWORK_ELECTRON_REMOTE_DEBUG_PORT=9826 pnpm dev', 'pnpm fraimz --flow <id> --cdp-url http://127.0.0.1:9826', 'pnpm fraimz scaffold <id>', plus the full ctx.* helper signatures and copy-paste bash blocks. Not a 5 because no complete flow example is inlined (usage is delegated to evals/flows/ files) and placeholders like <electron-cdp-url> and <printed-electron-cdp-url> are not resolvable without external docs.	4 / 5
Workflow Clarity	The loop is a clearly sequenced 6-step process with an explicit validation-and-repair feedback cycle ("Validate, repair, repeat... fix the visible state or the code and rerun until every claim has a passing assertion"), an explicit verdict gate ("Report Passed only when fraimz exists and every claim is backed by an observable assertion; otherwise Incomplete / Failed"), and a pitfalls section covering error recovery (stale dialogs, idempotency, readiness waits). This matches the anchor-5 pattern of clear sequence + explicit validation + error-recovery feedback loops.	5 / 5
Progressive Disclosure	No bundle files exist (references/, scripts/, assets/ are absent), and the body handles this well: it is a well-sectioned ~140-line overview whose 'Source of truth' section points one level deep to clearly labeled destinations (evals/README.md for the full reference, evals/flows/ for examples, evals/voiceovers/ for scripts). Not a 5 because the ctx.* helpers section partially duplicates the full reference in evals/README.md, and the referenced files live in the repo rather than a skill-local references/ file, so the skill is not self-contained if moved.	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.

A strong description with an explicit 'Use whenever...' trigger clause and a concrete, multi-action statement of what the skill does. Its main weaknesses are a redundant keyword list that repeats the coined term instead of diversifying synonyms, and broad verification phrases ('end-to-end proof', 'validate experience') that create some overlap risk with general verification skills.

Suggestions

Replace the redundant opening keyword run ('create a fraimz, make fraimz') with genuine natural-language variations users might say, e.g. 'fraimz proof', 'prove the change works end-to-end', 'demo evidence for the PR'.

Narrow the broad trigger 'any change needs end-to-end proof' toward the artifact itself (e.g. 'when a PR needs a fraimz.html proof artifact') to reduce overlap with generic verification/testing skills.

Name the concrete outputs (fraimz.html, report.md/report.json, PR comment) in the what-clause so the capability coverage is comprehensive rather than loop-level.

Dimension	Reasoning	Score
Specificity	The description lists several concrete actions — "frame the claim, drive the real app via CDP, validate/repair, output fraimz.html" — which goes beyond naming the domain. It falls short of a 5 because coverage is loop-level and leans on the coined term 'fraimz' rather than enumerating the concrete outputs and checks (PR comment, report.md/report.json, screenshot validation), and exceeds a 3 because more than 1-2 specific actions are named.	4 / 5
Completeness	Both 'what' and 'when' are answered explicitly: the what is the concrete loop ("frame the claim, drive the real app via CDP, validate/repair, output fraimz.html") and the when carries a concrete trigger phrase ("Use whenever a task ends with 'please create a fraimz' or any change needs end-to-end proof"). This matches the anchor-5 pattern of explicit what + when with concrete trigger phrases; a 4 would require the 'when' to be less explicit than it is.	5 / 5
Trigger Term Quality	Natural phrases users would say are present — "prove it works", "e2e evidence", "validate experience", "please create a fraimz", "end-to-end proof" — plus the artifact filename "fraimz.html". Not a 5 because the opening keyword list repeats the coined word ("create a fraimz, make fraimz") instead of adding genuine synonyms or variations, making it slightly redundant rather than comprehensive.	4 / 5
Distinctiveness Conflict Risk	The 'fraimz' niche is distinct with its own trigger term and artifact, so it is mostly distinguishable. Not a 5 because "any change needs end-to-end proof", "validate experience", and "e2e evidence" are broad verification phrases that could also match general testing/verification skills, creating minor overlap risk with closely related skills.	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: 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.