Menu
Verify browser-rendered work in a real browser. Use for HTML, UI, visual docs, presentations, local apps, and browser-facing changes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
| name | browser-verify |
| description | Verify browser-rendered work in a real browser. Use for HTML, UI, visual docs, presentations, local apps, and browser-facing changes. |
| user-invocable | true |
| argument-hint | <url, file, app route, or browser-facing change> |
Verify what the browser renders: layout, interaction, console, network, and visual defects.
Open the target with an available real-browser verification path. Use Chrome DevTools MCP, Playwright, in-app browser tooling, or another browser automation and inspection capability.
If no real-browser verification path is available, stop and tell the user browser verification cannot run until one is available.
Check the rendered page, not just the source.
If anything is broken, fix the source.
Reload and verify again. Repeat until defects are fixed.
Break a spec, brief, issue tracker item, or user request into agent-sized tasks, using phases and milestones only when they clarify larger work, delivered to exactly one destination.
Bootstrap a new or empty project repository with a local skeleton: README, license, .gitignore, AGENTS.md, docs, and optional commit or push only when explicit. Interview the repo creator when file-changing decisions are unclear.
Create a traceable Git branch for the current task.
Stage intended changes and create one Conventional Commit.
Find and fix the root cause when something breaks: a failing test, a broken build, a bug report, or behavior that doesn't match expectations. Use when the user says 'debug', 'why is this failing', 'fix this bug', or when a failure interrupts other work.
Write a lightweight technical design document for ambiguous or consequential architecture decisions before implementation.
