agentleFS
salalaslamsalalaslam/skills/proof-video/SKILL.md

proof-video

Skill0 starsChanged 39 days agoMITView on GitHub

Make a short MP4 that replays an agent coding session with real command outputs, to show a team that a bug is or isn't fixed, how quickly something can be fixed, or how to work a problem through with an AI agent. Use when asked for a proof video, walkthrough video, demo of how the agent would fix it, or a video to post on a ticket or PR.

  • Installs packages

We split this skill into the rules it gives an agent

3 rules. 0 are common, 0 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 13 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Write DIR/scenario.js: Start from assets/scenario.example.js.

    line 24
  2. Very specific:

    Check the length: Run node scripts/record.cjs DIR --dry, then adjust the pauses.

    line 25
  3. Very specific:

    Record: Run node scripts/record.cjs DIR --stills --out NAME.mp4.

    line 26

“Common” is measured: kept by at least 6 in 10 of the 13 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Proof video

A proof video is a scripted replay, not a screen recording. You do the real work first: reproduce the bug, run the old and new code, query the data. Then you replay those results in a window that looks like Claude Code Desktop, with typed prompts, tool calls and answers, and record it to a 1080p MP4.

People believe a video they can watch more than a long comment, and it shows them how to do the same work themselves.

Rules

  • Every output on screen is real. It must come from a command you ran in this session. Keep the scripts and raw outputs next to the scenario so anyone can check them. Never invent or round numbers. If you couldn't reach something, the video says so.
  • Say what it is once. The opening card says it replays real outputs. If nothing was pushed or changed, say that in the opening card only, not on every step.
  • No secrets or personal data. Mask IP addresses, hostnames, tokens, emails, phone numbers and customer personal data in outputs, file names and screenshots. Check the stills for them before handing the video over.
  • Plain words. Viewers often read English as a second language. Use short sentences, no jargon, and put the conclusion in bold.
  • Short. Aim for 2–5 minutes in 3–6 chapters. Keep each tool output to about 14 lines, because longer output is cut off on screen. Highlight the line that matters.

Steps

  1. Do the real work. Reproduce the issue with the actual code and data, for example by running the PR's code and the production code on the same input. Save each command's output to DIR/evidence/. Use a fresh directory per video, such as ~/videos/<topic>-<date>/.
  2. Agree the story. List the chapters and every prompt the viewer will see, and show that list to the user before writing the scenario. Users usually want to reword the prompts.
  3. Write DIR/scenario.js. Start from assets/scenario.example.js. Paste real outputs, set window.META for the window title, branch and session names, and put images such as screenshots or bug-report photos in DIR.
  4. Check the length. Run node scripts/record.cjs DIR --dry, then adjust the pauses.
  5. Record. Run node scripts/record.cjs DIR --stills --out NAME.mp4. It records at about real time, so a 4-minute video takes about 4 minutes.
  6. Look at it. Open the stills in DIR/out/stills/, or make a contact sheet with ffmpeg -i DIR/out/NAME.mp4 -vf "fps=1/15,scale=480:-1,tile=4x3" DIR/out/contact.jpg. Check for cut-off output, overlapping text, unmasked data and typos.
  7. Hand it over. Give the path and the length. Upload or post only when the user says so, with a short text: a TL;DR, what the video shows, and what still needs doing. For GitHub, keep the file under 10 MB: ffmpeg -i NAME.mp4 -vf scale=1280:-1 -crf 28 -preset slow NAME-small.mp4.

Scenario steps

window.SCENARIO is a list of steps. Each step uses one of these keys:

StepShowsOptions
{card: html, ms}Full-screen title cardms on screen, default 3500
{chapter: '2/4 · Name'}Chapter pill in the header ('' hides it)
{user: text}Prompt typed into the box, then sentpaste: true to drop it in at once, images: [...], files: [...] as attachments
{think: text}Short italic thinking linems
{tool, desc, out}Tool card with output printed line by linecmd typed first, kind: 'diff' colours +/-, lines starting !! are highlighted, img adds a screenshot, status replaces "done"
{ask, askCmd}Permission prompt; a pointer clicks "Allow once"
{say: text}Agent answer typed out; supports **bold**, `code`, - and 1. listspause after it
{sleep: ms}Pause

The block at the end of the example sets the reading pace. Keep it.

Setup

You need Node 18+, ffmpeg, and Playwright with Chromium (npm i playwright && npx playwright install chromium). If Playwright is installed somewhere else, set PLAYWRIGHT=/path/to/node_modules/playwright. Set CHROME=/path/to/chrome to use a specific browser build. The window template is assets/ui.html. The recorder copies it into DIR when DIR doesn't have one, so you can tweak a single video's window without changing the template.

Download now (ZIP)

  • Other versions13 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 13

    1. moltbot/moltbot★ 393ksame name
    2. clawdbot/clawdbot★ 393ksame name
    3. steipete/warelay★ 392ksame name
    4. moltbot/clawdbot★ 392ksame name
    5. steipete/clawdis★ 392ksame name
    6. molt-bot/clawdbot★ 391ksame name
    7. openclaw/openclaw★ 391ksame name
    8. openclaw/clawhub★ 9.5ksame name
    9. moltbot/molthub★ 9.5ksame name
    10. clawdbot/clawdhub★ 9.5ksame name

    3 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use discord-e2e, openclaw-repair-sweep and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • molt-botSkill

      discord-e2e

      Test Discord with Convex-leased QA bots: check credentials without a Gateway, exercise owned messages, or prove OpenClaw replies, files, threads, reactions, streaming, and typing. Distinguish API and Gateway evidence from manual user interactions.

      Also in 10 projects that use this

    • molt-botSkill

      openclaw-repair-sweep

      Run scoped OpenClaw issue/PR repair campaigns: coordinate workers, prove root causes, and land or close verified work under the requested authority.

      Also in 10 projects that use this

    • steipeteSkill

      plugin-sdk-impact

      Query how many public plugins use a Plugin SDK method, optionally by recent release date, and assess SDK deprecation or behavior changes using live ClawHub evidence.

      Also in 6 projects that use this

    • steipeteSkill

      pr-simplify

      Simplify your own change to its smallest complete fix. Use before opening a PR, before pushing large repairs to one, or when asked to shrink a PR or clean up slop.

      Also in 6 projects that use this

    • supermansuper563-opsSkill

      auto-qa

      Continuously audit, live-test, and stress-test the current OpenClaw codebase across at least ten independently scoped subsystem lanes; default to 100 independently verified, landed root-cause fixes, maintain an evidence-backed report, and announce each merged pull request immediately. Use for OpenClaw-wide autonomous QA, live-provider campaigns, gateway, CLI, web, plugin, native-app, scenario, packaging, and extended soak testing.

      Also in 10 projects that use this

    • clawsoulsSkill

      channel-message-flows

      Use when running QA Lab channel message flow evidence.

      Also in 10 projects that use this

    • +2 more from molt-bot
  • In this repository10 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.