Use when handed a runtime or browser verification task: prove a change actually works end-to-end in a running app, adversarially. Requires the Playwright MCP server (global mcp_config). Produces a verdict plus evidence other agents can audit.
Scanned 9/22/2026
Install to Claude Code
npx -y skills add jckeen/dotfiles --skill browser-verify --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Browser Verify?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/jckeen-browser-verify)More formats (shields.io, HTML) on the badges page.
---
name: browser-verify
description: "Use when handed a runtime or browser verification task: prove a change actually works end-to-end in a running app, adversarially. Requires the Playwright MCP server (global mcp_config). Produces a verdict plus evidence other agents can audit."
---
# Browser Verify
This is the runtime/browser verification lane from the multi-agent contract:
the conductor hands over a claim, this skill tries to BREAK it in a real
browser, and the verdict — with evidence — becomes an artifact the whole team
can audit.
## Required payload
A verification handoff must carry (ask for anything missing before starting):
1. **Target** — URL or route, and how to start the app if not running.
2. **Flow** — the exact steps to drive (click X, submit Y, expect Z).
3. **Expected observable** — what SHOULD happen, stated concretely.
4. **Claim to disprove** — the falsifiable statement under test.
## Workflow
1. Confirm the Playwright MCP tools are available (`/mcp` lists servers). If
absent, stop and report — do not fake a verification with static reading.
2. Start or reach the app; navigate the flow EXACTLY as specified first.
3. Then get adversarial: bad input, rapid repeats, back/forward, refresh
mid-flow, empty states, small viewport. You are here to refute the claim,
not confirm it.
4. Capture evidence as you go: screenshots at each decisive step, console
errors, failed network requests.
5. Copy evidence to the shared path other agents read:
`~/.claude/handoffs/evidence/YYYY-MM-DD-<short-slug>/`
(create it; screenshots, console log excerpts, a one-line INDEX.md naming
each file's moment).
6. Report the verdict:
- **REFUTED** — the claim broke: exact step, observed vs expected, evidence file.
- **HELD** — survived the specified flow AND the adversarial pass (list what was tried).
- **BLOCKED** — could not complete verification: what stopped it.
7. Write or append a handoff note (`~/.claude/handoffs/YYYY-MM-DD-<project>-handoff.md`)
with the verdict and the evidence path, so the verdict outlives this session.
## Rules
- A verdict without evidence files is not a verdict — capture before reporting.
- Disagreement with the conductor's claim is the valuable outcome; report it
plainly with the repro, never soften it to "mostly works".
- Never test against production with destructive inputs; use local/dev targets
unless the handoff explicitly says otherwise.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!