Update to Vercel

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 178
    }
  ],
  "skill_md_contents": "---\nname: verification\ndescription: \"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.\"\nmetadata:\n  priority: 7\n  docs:\n    - \"https://vercel.com/docs/projects/project-configuration\"\n  sitemap: \"https://vercel.com/sitemap/docs.xml\"\n  pathPatterns: []\n  bashPatterns:\n    - '\\bnext\\s+dev\\b'\n    - '\\bnpm\\s+run\\s+dev\\b'\n    - '\\bpnpm\\s+dev\\b'\n    - '\\bbun\\s+run\\s+dev\\b'\n    - '\\byarn\\s+dev\\b'\n    - '\\bvite\\s*(dev)?\\b'\n    - '\\bvercel\\s+dev\\b'\n    - '\\bastro\\s+dev\\b'\n  importPatterns: []\n  promptSignals:\n    phrases:\n      - \"verify the flow\"\n      - \"verify everything works\"\n      - \"test the whole thing\"\n      - \"does it actually work\"\n      - \"check end to end\"\n      - \"end to end test\"\n      - \"why isn't it working right\"\n      - \"why doesn't it work\"\n      - \"it's not working correctly\"\n      - \"something's off\"\n      - \"not quite right\"\n      - \"almost works but\"\n      - \"works locally but\"\n      - \"verify the feature\"\n      - \"make sure it works\"\n      - \"full verification\"\n    allOf:\n      - [verify, flow]\n      - [verify, works]\n      - [check, everything]\n      - [test, end, end]\n      - [not, working, right]\n      - [something, off]\n      - [almost, works]\n      - [make, sure, works]\n    anyOf:\n      - \"verify\"\n      - \"verification\"\n      - \"end-to-end\"\n      - \"full flow\"\n      - \"works\"\n      - \"working\"\n    noneOf:\n      - \"unit test\"\n      - \"jest\"\n      - \"vitest\"\n      - \"playwright test\"\n      - \"cypress test\"\n    minScore: 6\n---\n\n# Full-Story Verification\n\nYou 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.\n\nThis skill coordinates with `agent-browser-verify` (browser-side visual checks), `investigation-mode` (reactive debugging), and `observability` (logging/monitoring) — but your focus is the **end-to-end story**, not any single layer.\n\n## When This Triggers\n\n- A dev server just started and the user wants to know if things work\n- The user says something \"isn't quite right\" or \"almost works\"\n- The user asks you to verify a feature or check the full flow\n\n## Step 1 — Infer the User Story\n\nBefore checking anything, determine **what is being built**:\n\n1. Read recently edited files (check git diff or recent Write/Edit tool calls)\n2. Identify the feature boundary: which routes, components, API endpoints, and data sources are involved\n3. Scan `package.json` scripts, route structure (`app/` or `pages/`), and environment files (`.env*`)\n4. State the story in one sentence: _\"The user is building [X] which flows from [UI entry point] → [API route] → [data source] → [response rendering]\"_\n\n**Do not skip this step.** Every subsequent check must be anchored to the inferred story.\n\n## Step 2 — Establish Evidence Baseline\n\nGather the current state across all layers:\n\n| Layer | How to check | What to capture |\n|-------|-------------|-----------------|\n| **Browser** | Use `agent-browser` — open the relevant page, screenshot, check console | Visual state, console errors, network failures |\n| **Server terminal** | Read the terminal output from the dev server process | Startup errors, request logs, compilation warnings |\n| **Runtime logs** | Run `vercel logs` (if deployed) or check server stdout | API response codes, error traces, timing |\n| **Environment** | Check `.env.local`, `vercel env ls`, compare expected vs actual | Missing vars, wrong values, production vs development mismatch |\n\nReport what you find at each layer before proceeding. Use the investigation-mode reporting contract:\n\n> **Checking**: [what you're looking at]\n> **Evidence**: [what you found — quote actual output]\n> **Next**: [what this means for the next step]\n\n## Step 3 — Walk the Data Flow\n\nTrace the feature's data path from trigger to completion:\n\n1. **UI trigger** — What user action initiates the flow? (button click, page load, form submit)\n2. **Client → Server** — What request is made? Check the fetch/action call, verify the URL, method, and payload match the API route\n3. **API route handler** — Read the route file. Does it handle the method? Does it validate input? Does it call the right service/database?\n4. **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\n5. **Response → UI** — Does the response format match what the client expects? Is error handling present on both sides?\n\nAt each boundary, check for these common breaks:\n- **Missing `await`** on async operations\n- **Wrong HTTP method** (GET handler but POST fetch)\n- **Env var absent** in runtime but present in `.env.local`\n- **Import mismatch** (server module imported in client component or vice versa)\n- **Type mismatch** between API response and client expectation\n- **Missing error boundary** — unhandled rejection crashes the page silently\n\n## Step 4 — Report With Evidence\n\nSummarize findings in a structured report:\n\n```\n## Verification Report: [Feature Name]\n\n**Story**: [one-sentence description of the user story]\n\n### Flow Status\n| Boundary | Status | Evidence |\n|----------|--------|----------|\n| UI renders | ✅/❌ | [screenshot or console output] |\n| Client → API | ✅/❌ | [request/response or error] |\n| API → Data | ✅/❌ | [log output or error trace] |\n| Data → Response | ✅/❌ | [response shape or error] |\n| Response → UI | ✅/❌ | [rendered output or error] |\n\n### Issues Found\n1. [Issue]: [evidence] → [fix]\n\n### Verified Working\n- [What was confirmed working with evidence]\n```\n\n## Stop Conditions\n\n**Stop verifying when**:\n- All boundaries in the flow are confirmed working with evidence — report success\n- You find the **first broken boundary** — report it with evidence and a specific fix, do not continue past the break\n- 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\n\n**Do not**:\n- Run the same check more than twice\n- Continue past a confirmed broken boundary\n- Verify unrelated features — stay on the inferred story\n- Spend time on cosmetic issues (styling, spacing) unless the user specifically asked\n\n## Suggest Verification After Implementation\n\nWhen 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.\n\n## Coordination With Other Skills\n\n- **`agent-browser-verify`** — Handles browser screenshots and console checks. Defer to it for visual verification. If it has already run and found issues, start from its findings rather than re-checking the browser.\n- **`investigation-mode`** — Handles reactive debugging when things are stuck/hung. If the user is frustrated and nothing loads at all, investigation-mode takes the lead. Verification takes over when things _partially_ work.\n- **`observability`** — Handles logging/monitoring setup. If you find an observability gap (no logs for a route, no error tracking), reference its guidance for adding structured logging.\n"
}