/verification
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.
$ npx -y skills add vercel-labs/vercel-plugin --skill verification --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/verification
Context preview
The summary Claude sees to decide when to auto-load this 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.
SKILL.md
verification.SKILL.mdname: verification
description: "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."
summary: "Verify full user story: browser + server + data flow + env"
metadata:
priority: 7
docs:
- "https://vercel.com/docs/projects/project-configuration"
sitemap: "https://vercel.com/sitemap/docs.xml"
pathPatterns: []
bashPatterns:
- '\bnext\s+dev\b'
- '\bnpm\s+run\s+dev\b'
- '\bpnpm\s+dev\b'
- '\bbun\s+run\s+dev\b'
- '\byarn\s+dev\b'
- '\bvite\s*(dev)?\b'
- '\bvercel\s+dev\b'
- '\bastro\s+dev\b'
importPatterns: []
promptSignals:
phrases:
- "verify the flow"
- "verify everything works"
- "test the whole thing"
- "does it actually work"
- "check end to end"
- "end to end test"
- "why isn't it working right"
- "why doesn't it work"
- "it's not working correctly"
- "something's off"
- "not quite right"
- "almost works but"
- "works locally but"
- "verify the feature"
- "make sure it works"
- "full verification"
allOf:
- [verify, flow]
- [verify, works]
- [check, everything]
- [test, end, end]
- [not, working, right]
- [something, off]
- [almost, works]
- [make, sure, works]
anyOf:
- "verify"
- "verification"
- "end-to-end"
- "full flow"
- "works"
- "working"
noneOf:
- "unit test"
- "jest"
- "vitest"
- "playwright test"
- "cypress test"
minScore: 6
retrieval:
aliases:
- end to end test
- full stack verify
- flow test
- integration check
intents:
- verify full flow
- test end to end
- check if app works
- validate implementation
entities:
- browser
- API
- data flow
- end-to-end
- verification
chainTo:
-
pattern: 'process\.env\.\w+|NEXT_PUBLIC_\w+'
targetSkill: env-vars
message: 'Environment variable references detected during verification — loading Env Vars guidance for proper configuration, vercel env pull, and branch scoping.'
skipIfFileContains: 'vercel\s+env\s+pull|\.env\.local'
-
pattern: 'middleware\.(ts|js)|proxy\.(ts|js)|clerkMiddleware|NextResponse\.redirect'
targetSkill: routing-middleware
message: 'Middleware/proxy detected during verification — loading Routing Middleware guidance for request interception, auth checks, and proxy.ts migration.'
-
pattern: 'streamText\s*\(|generateText\s*\(|useChat\s*\('
targetSkill: ai-sdk
message: 'AI SDK calls detected during verification — loading AI SDK v6 guidance for streaming, transport, and error handling patterns.'
skipIfFileContains: 'toUIMessageStreamResponse|DefaultChatTransport'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**:
1. Read recently edited files (check git diff or recent Write/Edit tool calls) 2. Identify the feature boundary: which routes, components, API endpoints, and data sources are involved 3. Scan `package.json` scripts, route structure (`app/` or `pages/`), and environment files (`.env*`) 4. 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:
1. **UI trigger** — What user action initiates the flow? (button click, page load, form submit) 2. **Client → Server** — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route 3. **API route handler** — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database? 4. **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 5. **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
Read more
name: verification
description: "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."
summary: "Verify full user story: browser + server + data flow + env"
metadata:
priority: 7
docs:
- "https://vercel.com/docs/projects/project-configuration"
sitemap: "https://vercel.com/sitemap/docs.xml"
pathPatterns: []
bashPatterns:
- '\bnext\s+dev\b'
- '\bnpm\s+run\s+dev\b'
- '\bpnpm\s+dev\b'
- '\bbun\s+run\s+dev\b'
- '\byarn\s+dev\b'
- '\bvite\s*(dev)?\b'
- '\bvercel\s+dev\b'
- '\bastro\s+dev\b'
importPatterns: []
promptSignals:
phrases:
- "verify the flow"
- "verify everything works"
- "test the whole thing"
- "does it actually work"
- "check end to end"
- "end to end test"
- "why isn't it working right"
- "why doesn't it work"
- "it's not working correctly"
- "something's off"
- "not quite right"
- "almost works but"
- "works locally but"
- "verify the feature"
- "make sure it works"
- "full verification"
allOf:
- [verify, flow]
- [verify, works]
- [check, everything]
- [test, end, end]
- [not, working, right]
- [something, off]
- [almost, works]
- [make, sure, works]
anyOf:
- "verify"
- "verification"
- "end-to-end"
- "full flow"
- "works"
- "working"
noneOf:
- "unit test"
- "jest"
- "vitest"
- "playwright test"
- "cypress test"
minScore: 6
retrieval:
aliases:
- end to end test
- full stack verify
- flow test
- integration check
intents:
- verify full flow
- test end to end
- check if app works
- validate implementation
entities:
- browser
- API
- data flow
- end-to-end
- verification
chainTo:
-
pattern: 'process\.env\.\w+|NEXT_PUBLIC_\w+'
targetSkill: env-vars
message: 'Environment variable references detected during verification — loading Env Vars guidance for proper configuration, vercel env pull, and branch scoping.'
skipIfFileContains: 'vercel\s+env\s+pull|\.env\.local'
-
pattern: 'middleware\.(ts|js)|proxy\.(ts|js)|clerkMiddleware|NextResponse\.redirect'
targetSkill: routing-middleware
message: 'Middleware/proxy detected during verification — loading Routing Middleware guidance for request interception, auth checks, and proxy.ts migration.'
-
pattern: 'streamText\s*\(|generateText\s*\(|useChat\s*\('
targetSkill: ai-sdk
message: 'AI SDK calls detected during verification — loading AI SDK v6 guidance for streaming, transport, and error handling patterns.'
skipIfFileContains: 'toUIMessageStreamResponse|DefaultChatTransport'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**:
1. Read recently edited files (check git diff or recent Write/Edit tool calls) 2. Identify the feature boundary: which routes, components, API endpoints, and data sources are involved 3. Scan `package.json` scripts, route structure (`app/` or `pages/`), and environment files (`.env*`) 4. 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:
1. **UI trigger** — What user action initiates the flow? (button click, page load, form submit) 2. **Client → Server** — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route 3. **API route handler** — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database? 4. **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 5. **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
Comprehensive Vercel ecosystem plugin — relational knowledge graph, skills for every major product, specialized agents, and Vercel conventions. Turns any AI agent into a Vercel expert.
Repo: vercel-labs/vercel-plugin
Other skills on vercel.
- /benchmark-agents
Advanced AI agent benchmark scenarios that push Vercel's cutting-edge platform features — Workflow DevKit, AI Gateway, MCP, Chat SDK, Queues, Flags, Sandbox, and multi-agent orchestration. Designed to stress-test skill injection for complex, multi-system builds.
Open skill - /benchmark-e2e
End-to-end benchmark suite for vercel-plugin. Runs realistic projects through skill injection, launches dev servers, verifies everything works, analyzes conversation logs, and produces an improvement report for overnight self-improvement loops.
Open skill - /benchmark-sandbox
Run vercel-plugin eval scenarios in Vercel Sandboxes instead of local WezTerm panels. Provisions ephemeral microVMs with Claude Code + plugin pre-installed, runs benchmark prompts, extracts hook artifacts, and produces coverage reports.
Open skill - /benchmark-testing
Create and launch benchmark test projects to exercise vercel-plugin skill injection across realistic scenarios. Sets up isolated directories, installs the plugin, and spawns WezTerm panes running Claude Code with crafted prompts.
Open skill - /plugin-audit
Audit vercel-plugin performance on real-world projects. Extracts tool calls from Claude Code conversation logs, tests hook matching against actual inputs, identifies pattern coverage gaps, and checks plugin cache staleness. Use when asked to audit, test, or investigate plugin
Open skill - /release
Release vercel-plugin — run gates, bump version, generate artifacts, commit, and push. Use when asked to "release", "ship", "bump and push", or "cut a release".
Open skill

