# Fraimz

Create a fraimz, make fraimz, prove it works, frame proof, PR proof, validate...

- Repository: https://github.com/Devin-AXIS/iPolloWork (7348 stars)
- Category: Testing
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add Devin-AXIS/iPolloWork --skill fraimz -g -a claude-code -y`
Codex: `npx skills add Devin-AXIS/iPolloWork --skill fraimz -g -a codex -y`
Cursor: `npx skills add Devin-AXIS/iPolloWork --skill fraimz -g -a cursor -y`
Gemini CLI: `npx skills add Devin-AXIS/iPolloWork --skill fraimz -g -a gemini-cli -y`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Skill: fraimz

**fraimz** is the canonical proof artifact: a single `fraimz.html`
(`evals/results/<run-id>/fraimz.html`) with one frame per step. Each frame binds
a **claim**, the **action** the end user took, the **assertion** that witnesses
the side effect, a **voiceover** that narrates the step, and a validated
**screenshot**. It is the thing a human looks at (and listens to) to understand,
at a glance, that an experience works.

This skill owns the prove-it loop. In the demo-driven journey (`voiceover`
skill: script → worktree → build → fraimz → PR) this is how the build is
verified; when orchestrating, the orchestrator drives this loop and delegates
code repairs to the executor.

## Every fraimz is a demo

A fraimz is never a bare test log. The flow declares which demo it is via
`kind` in `evals/flows/<id>.flow.mjs`:

- **`kind: "user-facing"`**, the end user is the protagonist; the frames walk
  a real journey through the UI. Default for any feature, fix, or UX change.
- **`kind: "internal"`**, for changes with no visible surface (perf, storage
  swaps, invariants, refactors): the frames demonstrate the internal claim in
  a way a reviewer can still follow. Terminal/tooling demos may set
  `requiresApp: false` to run without CDP; their frames carry claims,
  assertions, and `ctx.output` command output instead of screenshots (see
  `evals/flows/voiceover-first-dx.flow.mjs`).

If you cannot say which of the two your fraimz is, you have not framed the
experience yet.

## Voiceover first

The rest: https://github.com/Devin-AXIS/iPolloWork/blob/HEAD/.opencode/skills/fraimz/SKILL.md