| name | visual-check |
| description | Visually verify web UI using a rubber duck MCP with Chrome browser tools. Use after building or modifying web UI components. |
| argument-hint | [page-path] [checklist items...] |
Visual Check
Visually verify the web UI by using a rubber duck (MCP) with Chrome browser tools.
As a verification skill
verify_skill: visual-check is a valid ## Verification value in a project's CLAUDE.md. When set, /implement's Phase 4b″ runs /dev-process-toolkit:visual-check — with its built-in MCP-probe path and manual-checklist fallback — as the per-FR verification pass. This is the zero-authoring verification path for web UIs: declare it and get visual verification without writing a project-local check skill.
Process
0. Check MCP availability
Before anything else, check if the rubber duck MCP is available:
- Attempt a
list_ducks MCP call
- If the call succeeds, proceed to step 1
If the call fails or returns an error, MCP is unavailable. Display:
⚠️ mcp-rubber-duck is not configured. See setup instructions to enable automated visual verification.
Then fall back to the manual verification path below.
Manual Verification Checklist
When MCP is unavailable, guide the user through manual checks:
Report results as a pass/fail summary:
- ✓ Description of what passed
- ✗ Description of what failed
Then skip to step 4 (clean up).
1. Ensure the dev server is running
Detect the dev server URL from the project's CLAUDE.md or config files (e.g., package.json scripts, vite.config). Default: http://localhost:5173.
Check if the dev server is reachable:
curl -s -o /dev/null -w "%{http_code}" http://localhost:5173
- If it returns
200, proceed.
- If not, start the server (run in background), wait a few seconds, then re-check.
2. Ask a duck to verify the page
Use ask_duck to have a duck open the page in Chrome and verify it visually. The duck should NOT run shell commands — it should only use its Chrome/browser MCP tools.
The default page is / unless $ARGUMENTS specifies a different path.
Base verification (always check)
Ask the duck to open the page and report:
- Does the page render without errors?
- Is the layout correct (no broken styles, overlapping elements, missing content)?
- Are all expected UI elements visible?
Interaction testing (if applicable)
After verifying the base page, ask the duck to check interactive elements:
- Navigation between pages
- Filter/form changes via URL params
- Dynamic content updates
Custom checklist
If $ARGUMENTS includes specific items to check, verify those as well.
3. Report results
Summarize findings as a pass/fail checklist:
- ✓ Page renders correctly
- ✓ Layout and styling look good
- ✗ [Any issues found]
4. Clean up
Kill the dev server if you started it.
Prerequisites
- Optional: mcp-rubber-duck — an MCP server that delegates tasks to independent AI "ducks," each with their own tools and context. Improves quality through cross-model evaluation and enables this skill to have a duck visually inspect pages in Chrome. Without it, the
ask_duck calls will fail and this skill won't work.
chrome-devtools-mcp should be configured in .mcp.json for direct Chrome access from Claude Code. The duck may also have its own Chrome MCP tools configured separately. /setup configures .mcp.json automatically for web-based stacks.
Notes
- The duck uses Chrome browser MCP tools — it should NOT run shell commands
- For SPA pages, the duck needs to navigate to the full URL — WebFetch won't work for client-rendered apps
