Verification Agent Skill

Full-story verification — infers what the user is building, then verifies the complete flow end-to-end: browser → API → data → response. Triggers on dev server start and 'why isn't this working' signals.

2k tokens

context cost

the whole folder, loaded on every use

files

instructions only

copies elsewhere

how many repositories repackaged it

240

stars on the repo

on the repository, not the skill itself

Install

one command, takes just this skill from the repository

npx skills add https://github.com/vercel/vercel-plugin --skill verification

What it tells the agent to use

found in the instruction text

Edit edits files in place

The instruction itself

8 sections, as written by the author

Full-Story Verification

You are a verification orchestrator. Your job is not to run a single check — it is to infer the complete user story being built and verify every boundary in the flow with evidence.

Your focus is the end-to-end story, not any single layer.

When This Triggers

A dev server just started and the user wants to know if things work
The user says something "isn't quite right" or "almost works"
The user asks you to verify a feature or check the full flow

Step 1 — Infer the User Story

Before checking anything, determine what is being built:

Read recently edited files (check git diff or recent Write/Edit tool calls)
Identify the feature boundary: which routes, components, API endpoints, and data sources are involved
Scan package.json scripts, route structure (app/ or pages/), and environment files (.env*)
State the story in one sentence: _"The user is building [X] which flows from [UI entry point] → [API route] → [data source] → [response rendering]"_

Do not skip this step. Every subsequent check must be anchored to the inferred story.

Step 2 — Establish Evidence Baseline

Gather the current state across all layers:

| Layer | How to check | What to capture |

|-------|-------------|-----------------|

| Browser | Open the relevant page, check console, take screenshots | Visual state, console errors, network failures |

| Server terminal | Read the terminal output from the dev server process | Startup errors, request logs, compilation warnings |

| Runtime logs | Run vercel logs (if deployed) or check server stdout | API response codes, error traces, timing |

| Environment | Check .env.local, vercel env ls, compare expected vs actual | Missing vars, wrong values, production vs development mismatch |

Report what you find at each layer before proceeding. Use this reporting contract:

> Checking: [what you're looking at]

> Evidence: [what you found — quote actual output]

> Next: [what this means for the next step]

Step 3 — Walk the Data Flow

Trace the feature's data path from trigger to completion:

UI trigger — What user action initiates the flow? (button click, page load, form submit)
Client → Server — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route
API route handler — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database?
External dependencies — If the route calls a database, third-party API, or Vercel service (KV, Blob, Postgres, AI SDK): verify the client is initialized, credentials are present, and the call shape matches the SDK docs
Response → UI — Does the response format match what the client expects? Is error handling present on both sides?

At each boundary, check for these common breaks:

Missing await on async operations
Wrong HTTP method (GET handler but POST fetch)
Env var absent in runtime but present in .env.local
Import mismatch (server module imported in client component or vice versa)
Type mismatch between API response and client expectation
Missing error boundary — unhandled rejection crashes the page silently

Step 4 — Report With Evidence

Summarize findings in a structured report:

## Verification Report: [Feature Name]

**Story**: [one-sentence description of the user story]

### Flow Status
| Boundary | Status | Evidence |
|----------|--------|----------|
| UI renders | ✅/❌ | [screenshot or console output] |
| Client → API | ✅/❌ | [request/response or error] |
| API → Data | ✅/❌ | [log output or error trace] |
| Data → Response | ✅/❌ | [response shape or error] |
| Response → UI | ✅/❌ | [rendered output or error] |

### Issues Found
1. [Issue]: [evidence] → [fix]

### Verified Working
- [What was confirmed working with evidence]

Stop Conditions

Stop verifying when:

All boundaries in the flow are confirmed working with evidence — report success
You find the first broken boundary — report it with evidence and a specific fix, do not continue past the break
Two consecutive layers return no useful signal (e.g., no logs, no errors, no output) — flag the observability gap and recommend adding logging before continuing

Do not:

Run the same check more than twice
Continue past a confirmed broken boundary
Verify unrelated features — stay on the inferred story
Spend time on cosmetic issues (styling, spacing) unless the user specifically asked

Suggest Verification After Implementation

When you finish building or implementing a feature (wrote code, created routes, set up a project), briefly let the user know they can ask you to verify everything works — e.g. browser verification or end-to-end flow check. One sentence is enough. Don't force it if only a small fix or question was involved.

Other skills for the same job

different authors, same section of the catalogue

Python Executor

by ComeOnOliver

×1

Execute Python code in a safe sandboxed environment via [inference.sh](https://inference.sh). Pre-installed: NumPy, Pandas, Matplotlib, requests, BeautifulSoup, Selenium, Playwright, MoviePy, Pillow, OpenCV, trimesh, and 100+ more libraries. Use for: data processing, web scraping, image manipulation, video creation, 3D model processing, PDF generation, API calls, automation scripts. Triggers: python, execute code, run script, web scraping, data analysis, image processing, video editing, 3D models, automation, pandas, matplotlib

Upgrade browser versions (Chrome or Firefox) in the Flutter Web Engine and/or Framework tests. Use when asked to roll or upgrade Chrome or Firefox to a newer version.

Migrate PowerToys module UI tests from the legacy WinAppDriver/Selenium harness (Microsoft.PowerToys.UITest) to the new winappcli-based harness (Microsoft.PowerToys.UITest.Next). Use when asked to port/convert/rewrite/modernize a module's UI tests to the .Next framework, create a new [Module].UITests.Next project alongside existing legacy tests, or stand up brand-new winappcli UI tests for a module that has none by reading its human test sign-off markdown. Covers the API mapping (By/Element/Session/UITestBase, KeyboardHelper/MouseHelper/ClipboardHelper), project/csproj scaffolding, naming rules, common PowerToys test recipes (toggle a module, read an activation shortcut, fire a global hotkey, inspect the clipboard, discover overlay/editor windows), build/run validation, and CI-stability hardening for fewer CI iterations. Keywords: UI test, UITests, UITestAutomation.Next, winappcli, WinAppDriver, Selenium, migrate, port, modernize, .Next, MSTest, CI stability, flaky test, stabilize on CI.

32k tokens

Open Source

by browser-use

> Documentation reference for writing Python code using the browser-use open-source library. Use this skill whenever the user needs help with Agent, Browser, or Tools configuration, is writing code that imports from browser_use, asks about @sandbox deployment, supported LLM models, Actor API, custom tools, lifecycle hooks, MCP server setup, or monitoring/observability with Laminar or OpenLIT. Also trigger for questions about browser-use installation, prompting strategies, or sensitive data handling. Do NOT use this for Cloud API/SDK usage or pricing — use the cloud skill instead. Do NOT use this for directly automating a browser via CLI commands — use the browser-use skill instead.

Run agent-browser + Chrome inside Vercel Sandbox microVMs for browser automation from any Vercel-deployed app. Use when the user needs browser automation in a Vercel app (Next.js, SvelteKit, Nuxt, Remix, Astro, etc.), wants to run headless Chrome without binary size limits, needs persistent browser sessions across commands, or wants ephemeral isolated browser environments. Triggers include "Vercel Sandbox browser", "microVM Chrome", "agent-browser in sandbox", "browser automation on Vercel", or any task requiring Chrome in a Vercel Sandbox.

Use the browse CLI for Browserbase browser automation, Browserbase cloud APIs, Browserbase Functions, templates, web fetch/search, diagnostics, and Browse.sh skill discovery/installation. Use when the user asks to navigate pages, inspect browser state, run local or remote browser sessions, manage Browserbase resources, call Browserbase Functions, browse or scaffold Browserbase templates, fetch or search web content, diagnose browse setup, find or install a skill for a website task, discover site-specific Browse.sh skills, or install/refresh this browse skill.

Development workflows for the playwright-cli repository. Use when the user asks about rolling dependencies, releasing, or other repo maintenance tasks.

2k tokens

How to use it

Copy the folder

Take vercel/verification from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.