proofshot
CLAUDE.md866 starsChanged 9 months agoMITView on GitHub
Visual verification tool for AI coding agents. Records browser sessions, captures screenshots, collects errors, and bundles proof artifacts. Entry point: bin/proofshot.ts → src/cli.ts → src/commands/*.ts Edit src/utils/error-patterns.ts — add a new entry to the PATTERNS array:
In this repository4 other files it gives its agents.
- skills/codex/AGENTS.mdAGENTS.md
- proofshotSkill
- proofshotSkill
- proofshotSkill
The file
We split this CLAUDE.md into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 47
Create src/commands/mycommand.ts with export async function mycommandCommand(options): Promise<void>
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
ProofShot CLI
Visual verification tool for AI coding agents. Records browser sessions, captures screenshots, collects errors, and bundles proof artifacts.
Quick reference
npm run build # Build with tsup (must run after changes)
npm test # Run vitest once
npm run dev # Watch mode buildArchitecture
src/
├── cli.ts # Commander.js command registration
├── commands/ # One file per CLI command (install, start, stop, exec, diff, pr, clean)
├── browser/ # agent-browser CLI wrappers (session, capture, interact, navigate)
├── server/ # Dev server detection, startup, port waiting
├── session/state.ts # .session.json lifecycle (save/load/clear)
├── session/metadata.ts # Persistent per-session metadata (branch, commit) for PR matching
├── artifacts/ # Output generation (viewer.html, SUMMARY.md, PR format)
└── utils/ # Config, exec helpers, port utils, error patterns, GitHub APIEntry point: bin/proofshot.ts → src/cli.ts → src/commands/*.ts
Key conventions
- ESM only — all imports MUST use
.jsextensions:import { foo } from '../utils/config.js' - Build before test — CLI runs from
dist/, alwaysnpm run buildafter code changes - agent-browser — external peer dependency (Rust CLI + Node daemon). All browser commands go through
ab()inutils/exec.tswhich callsagent-browser <command>viaexecSync - Session state —
startwrites.session.json,execandstopread it.stopclears it. Don't assume session exists without checking - Session metadata —
startwritesmetadata.jsoninside each session folder with git branch/commit. This persists afterstopand is used byprto match sessions to branches - Per-session subfolders — artifacts go in
proofshot-artifacts/YYYY-MM-DD_HH-mm-ss_slug/
Command lifecycle
proofshot start— spawns dev server, opens browser, starts recording, saves session state + writesmetadata.jsonwith git branch/commitproofshot exec <args>— logs action tosession-log.json, forwards toagent-browserproofshot stop— collects errors, stops recording, trims video, generates SUMMARY.md + viewer.html, clears sessionproofshot pr [number]— finds sessions for current branch, uploads artifacts to GitHub, posts PR comment
Adding a new command
- Create
src/commands/mycommand.tswithexport async function mycommandCommand(options): Promise<void> - Register in
src/cli.tswithprogram.command('mycommand')... - Export from
src/index.tsif it should be part of the public API
Adding error patterns for a new language
Edit src/utils/error-patterns.ts — add a new entry to the PATTERNS array:
{
name: 'Swift',
patterns: [
/Fatal error:/,
/Thread \d+: signal SIGABRT/,
],
},Session artifacts
| File | Created by | Contains |
metadata.json | start | Git branch, commit SHA, timestamp (persists after stop) |
session.webm | start | Video recording (Playwright screencast) |
session-log.json | exec (appended each call) | Action timeline with relative timestamps |
server.log | start (piped stdout+stderr) | All dev server output |
console-output.log | stop | Browser console output |
step-*.png | exec screenshot | Screenshots at key moments |
SUMMARY.md | stop | Markdown report with errors and screenshots |
viewer.html | stop | Standalone HTML viewer with video + timeline |
Versioning & releases
- Automatic — merging to
maintriggers semantic-release via GitHub Actions - Never manually edit
versionin package.json — semantic-release handles it - Conventional Commits determine the version bump:
feat:→ minor (0.1.0 → 0.2.0)fix:,perf:,refactor:→ patch (0.2.0 → 0.2.1)feat!:orBREAKING CHANGE:footer → major (0.2.1 → 1.0.0)docs:,style:,chore:,test:,ci:→ no release
- Commit format:
type(scope): description— e.g.feat(cli): add diff command,fix(viewer): correct timestamp offset - Branch naming:
AmElmo/<descriptive-name>
Gotchas
proofshot exechas special shell quoting logic (buildShellCommandin exec.ts) —evalcommands get single-quoted, args with special chars get auto-quoted- Video trimming adjusts session-log.json timestamps to match the trimmed video (see
trimOffsetSecin stop.ts) - Server log capture only works when proofshot starts the server itself — if the port is already occupied, we skip spawning and get no server logs
- The
consoleErrors/consoleOutputfrom agent-browser are point-in-time snapshots collected at stop time
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

