proofshot
Skill866 starsChanged 9 months agoMITView on GitHub
Visual verification of UI features. Use after building or modifying any
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- schepens83/claude-skillsedited, first seen Apr 28, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- schepens83/claude-skills★ 194% same
Wrote their own version · 0
None found.
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.
In this repository4 other files it gives its agents.
- skills/codex/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- proofshotSkill
- proofshotSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 33
Only omit --run if the server was explicitly started by the user or another process - without it, no server logs are captured.
- Very specific: line 35
If a previous session was not stopped cleanly, add --force to override it.
- Very specific: line 39
Use proofshot exec to navigate, interact, and verify:
- Distinctive: line 50
Verify what you expect to see by reading the snapshot output.
- Very specific: line 72
Always include a meaningful --description so the human knows what was tested
- Distinctive: line 74
If you find errors during verification, fix them and re-run the workflow
- Very specific: line 75
Use proofshot pr after stopping to attach proof directly to the pull request
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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 - Visual Verification Workflow
ProofShot is an open-source, agent-agnostic CLI that lets you verify your own work in a real browser - video proof, screenshots, and error reports, no vendor lock-in.
When to use
Use ProofShot after:
- Building a new UI feature or page
- Modifying existing UI components
- Fixing a visual bug
- Any change that affects what the user sees
The workflow (always follow these 3 steps)
Step 1: Start the session
proofshot start --run "your-dev-command" --port PORT --description "what you are about to verify"This opens a browser and begins recording. If the port is already in use, proofshot will kill the existing process automatically.
Always use --run to let proofshot start and capture your dev server output (server logs appear in the proof report).
Only omit --run if the server was explicitly started by the user or another process - without it, no server logs are captured.
If a previous session was not stopped cleanly, add --force to override it.
Step 2: Drive the browser and test
Use proofshot exec to navigate, interact, and verify:
proofshot exec snapshot -i # See interactive elements
proofshot exec open http://localhost:PORT/page # Navigate to a page
proofshot exec click @e3 # Click a button
proofshot exec fill @e2 "test@example.com" # Fill a form field
proofshot exec screenshot step-NAME.png # Capture key momentsTake screenshots at important moments - these become the visual proof. Verify what you expect to see by reading the snapshot output.
Step 3: Stop and bundle the proof
proofshot stopThis stops recording, collects console + server errors, and generates a SUMMARY.md with video, screenshots, and error report.
Step 4 (optional): Post proof to the PR
proofshot pr # Auto-detect PR from current branch
proofshot pr 42 # Target a specific PR numberThis uploads screenshots and video to GitHub and posts a formatted comment on the PR. By default it uses the official GitHub contents API on a proofshot-artifacts branch. Use --upload-provider github-web-attachments if you specifically want GitHub attachment URLs.
Tips
- Always include a meaningful --description so the human knows what was tested
- Take screenshots before AND after key actions (e.g., before form submit, after redirect)
- If you find errors during verification, fix them and re-run the workflow
- Use
proofshot prafter stopping to attach proof directly to the pull request
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.

