agentsclimarketplace

Visual validate

Skill helderberto/agent-skills/skills/visual-validate

My personal SDLC toolbelt for AI coding agents — PRD to ship.

Install
npx -y skills add helderberto/agent-skills --skill visual-validate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Validate UI changes in a real browser using Chrome DevTools or Playwright MCP. Takes screenshots, compares before/after, exercises interactions, captures console errors. Use when user asks to "visual validate", "/visual-validate", "check the UI", "screenshot before/after", or finishes a UI change. Don't use for unit tests (use `tdd`), E2E user flows (use `e2e`), or backend changes.

SKILL.md

4.0 KB, as published. Nobody here has run it

Visual Validate

Drive a real browser via MCP to verify a UI change works as intended. Auto-detects which browser MCP is available (chrome-devtools preferred, playwright fallback). Screenshots, interactions, and console capture confirm the change is real — not just type-checked.

MCP Auto-Detection

Prefer chrome-devtools MCP tools (mcp__chrome-devtools__*); fall back to playwright (mcp__playwright__*) if absent. If neither is available, STOP and tell the user to install one. State the detected MCP at the start: "Using chrome-devtools MCP for visual validation."

Workflow

Phase 1 — Setup

  1. Confirm the dev server URL with the user (default to http://localhost:3000 if a Next.js/Vite project is detected; otherwise ask).
  2. If the dev server is not running, ask the user to start it. Do NOT start it automatically — port collisions are easy and dev servers are user state.
  3. Open the page via the detected MCP:
    • chrome-devtools: new_page → navigate_page
    • playwright: equivalent navigate tool

Phase 2 — Capture baseline (before)

  1. Take a "before" screenshot of the relevant page/component. Save reference to it.
  2. Capture the initial console state.
  3. If the user provides a specific element or component to focus on, take an element-scoped screenshot via DOM snapshot.

Phase 3 — Exercise the change

  1. Ask the user what interactions to validate (e.g., "click the toggle", "submit form with X data", "resize to mobile width").
  2. Execute interactions via MCP:
    • chrome-devtools: click, fill, hover, press_key, resize_page
    • playwright: equivalent tools
  3. Wait for any animations / network requests to settle (wait_for or equivalent).

Phase 4 — Capture after

  1. Take "after" screenshot(s).
  2. Capture console messages and any new network errors via list_console_messages and list_network_requests.
  3. Run accessibility audit on the final state via lighthouse_audit (chrome-devtools) if available.

Phase 5 — Report

  1. Present findings in this structure:
## Visual Validation — <feature>

**MCP**: chrome-devtools (or playwright)
**URL**: <url>
**Interactions exercised**: <list>

### Screenshots
- Before: <path or reference>
- After: <path or reference>

### Console
- Errors: <count> — <summary>
- Warnings: <count>

### Network
- Failed requests: <count>
- Slow requests (>1s): <count>

### Accessibility (if lighthouse_audit ran)
- Score: <n>
- Critical issues: <list>

### Verdict
- PASS: change works as intended, no new console errors, no a11y regressions
- FAIL: console errors / a11y regressions / unexpected visual changes — list each issue with screenshot reference

Rules

  • Never modify files during validation; this is read-only browser interaction
  • Always close the browser page at the end (close_page) to free resources
  • Capture console messages even on PASS — silent regressions surface in console first

Error Handling

  • No MCP available → STOP with installation hint (chrome-devtools or playwright MCP server setup)
  • Dev server unreachable → ask user to confirm URL and start the server
  • Navigation timeout (>30s) → report and stop; likely a build error or wrong URL
  • MCP tool errors mid-flow → report which step failed, attempt cleanup (close_page), stop

Choosing chrome-devtools vs playwright

  • chrome-devtools: DevTools-specific features — lighthouse audit, network throttling, performance profiling, memory snapshots.
  • playwright: cross-browser testing (Firefox, Safari/WebKit) or an existing Playwright setup.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.