plugins/pokayokay/skills/browser-verification/SKILL.md
Automatically verify UI changes in a real browser after implementation. Integrated into the /work workflow — checks visual elements, interactions, and console errors using Playwright. Not a standalone skill.
npx skillsauth add srstomp/pokayokay browser-verificationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Automatically verify UI changes in a real browser after implementation.
This skill is triggered during the /work workflow after the implementer completes a task that modifies UI-related files. It is NOT a standalone skill - it's integrated into the work loop.
Catch visual and functional issues before code review by testing in a real browser. This prevents:
Browser verification only runs when ALL three conditions are met:
Must have either:
mcp__plugin_playwright_*)mcp__claude-in-chrome__*)Must have an HTTP server on a dev port (3000-8999) or ability to start one via package.json scripts.
Task must have modified files that affect browser output:
.html, .css, .scss, .less.tsx, .jsx, .vue, .svelte.hbs, .ejs, .pug)components/, views/, ui/, pages/If any condition fails, verification is silently skipped.
This is NOT a hard gate. If verification suggests issues but the user believes the implementation is correct:
Projects can customize in .pokayokay.json:
{
"browserVerification": {
"enabled": true,
"portRange": [3000, 9999],
"additionalPaths": ["src/templates/"],
"excludePaths": ["src/email-templates/"]
}
}
references/testability-detection.md - How to determine if verification should runreferences/verification-flow.md - Step-by-step verification processreferences/configuration.md - Project-level configuration optionsyokay-implementer → browser-verify → yokay-spec-reviewer → yokay-quality-reviewer → complete
Browser verification runs AFTER implementation and BEFORE spec review.
development
Git worktree management for isolated task development
development
Use when starting AI development sessions, resuming interrupted work, managing multi-session projects, or orchestrating work with human checkpoint control (supervised, semi-auto, auto, or unattended modes).
testing
Use before claiming work is done, fixed, passing, ready to commit, ready to PR, or ready to mark complete. Requires fresh verification evidence and explicit command output before success claims.
development
Use when designing test architecture, building API test suites, validating API contracts, setting up component or E2E testing, managing test data, debugging flaky tests, reviewing coverage strategy, or organizing test files. Covers test pyramid, mocking (MSW), frontend (React Testing Library, Playwright), and CI integration.