vercel

Vercel

Three modes. Pick based on intent:

========================================

Deploy mode — deploy to production or preview

Deploy to Vercel with pre-flight checks, build monitoring, health verification, and post-deploy review.

Instructions

Follow these steps exactly in order. Do NOT skip the user confirmation gate in Step 2.

---

Step 0: Prerequisites

Run these checks in order. Stop at the first failure and guide the user.

1. CLI installed?

vercel --version

• If the command fails (non-zero exit code or "command not found"): tell the user to install with npm install -g vercel

2. Authenticated?

vercel whoami

• If the command fails: tell the user to run vercel login

3. Project linked?

ls .vercel/project.json

• If the file does not exist: tell the user to run vercel link to select a project

---

Step 1: Pre-Deploy Check

Gather context about what's about to be deployed.

Vercel context:

vercel ls --limit 1

Parse: project name, current production URL, last deployment status.

Git context:

git log -1 --oneline
git status --porcelain

Warn if uncommitted changes exist. By default vercel deploys from the working directory — uncommitted changes WILL be included in a CLI deploy but NOT in git-triggered deploys. This causes drift.

Check deploy target:

• If the user said "deploy to production" → --prod flag
• If the user didn't specify → default is preview deployment
• Ask if unclear: "Deploy to production or preview?"

Check for build errors locally (optional but recommended):

npm run build

If the build fails locally, warn the user before proceeding.

Present a pre-deploy summary:

Deploy Summary
═══════════════════════════════════════════════════════
  Project:      [name]
  Target:       [production / preview]
  Branch:       [git branch]
  Commit:       [short hash] [message]
  Uncommitted:  [Y/N — warn if Y]
  Local build:  [passed / failed / skipped]
═══════════════════════════════════════════════════════

Step 2: User Confirmation Gate

Ask the user: "Ready to deploy? (y/n)"

Do NOT proceed until the user explicitly confirms. If they say no, stop and ask what they'd like to change.

Step 3: Deploy

Preview deployment (default):

vercel deploy

Production deployment:

vercel deploy --prod

The CLI streams build output. Monitor for:

• Build errors (exit code != 0)
• Function bundling warnings
• Size limit warnings (serverless functions > 50MB compressed)

Capture the deployment URL from the CLI output.

If the project uses Git Integration (auto-deploy on push): Tell the user: "This project uses Vercel Git Integration. Push your changes with git push and Vercel will build automatically. I'll check the deployment status."

Then monitor:

vercel ls --limit 1

Poll until the deployment state changes from BUILDING to READY or ERROR.

Step 4: Health Check

After the deployment is ready:

Get the deployment URL (captured from Step 3 output or from vercel ls):

curl -s -o /dev/null -w "%{http_code}" <deployment-url>

• 200-299 → healthy
• 301-399 → redirect (follow and check final destination)
• 4xx/5xx → unhealthy, flag immediately
• Connection timeout → deployment may still be propagating, wait 10s and retry once

Check specific routes if known:

curl -s -o /dev/null -w "%{http_code}" <deployment-url>/api/health
curl -s -o /dev/null -w "%{http_code}" <deployment-url>/api

If the project has API routes, test at least one.

Step 5: Post-Deploy Log Review

vercel logs <deployment-url> --limit 50

Check for:

• Serverless function errors (timeouts, crashes)
• Edge function errors
• 500-level responses
• Cold start issues (function initialization errors)
• Missing environment variables (undefined/null config references)

Step 6: Deploy Report

Present a final summary:

Deploy Report
═══════════════════════════════════════════════════════
  Status:       [READY / ERROR / BUILDING]
  Target:       [production / preview]
  URL:          [deployment URL]
  Commit:       [hash] [message]
  Build:        [duration if available]
  Health:       [HTTP status]
  Functions:    [count serverless, count edge]
  Errors:       [count of errors in logs]
═══════════════════════════════════════════════════════

If the deploy failed or health checks are unhealthy:

• Show the relevant error logs
• Suggest checking vercel logs <url> --limit 100
• Offer to rollback: vercel rollback restores the previous production deployment
• Offer to redeploy: vercel redeploy triggers a fresh build

For production deployments that succeed:

• Confirm the production domain is serving the new deployment
• Check that the preview URL also works (useful for sharing with the team)

$ARGUMENTS

========================================

Logs mode — view, filter, or stream deployment logs

View and filter Vercel deployment logs. The CLI supports native filtering by level, status code, source type, time range, and full-text search — with JSON output for parsing.

Instructions

Follow these steps exactly in order.

---

Step 0: Prerequisites

Run these checks in order. Stop at the first failure and guide the user.

1. CLI installed?

vercel --version

• If the command fails (non-zero exit code or "command not found"): tell the user to install with npm install -g vercel

2. Authenticated?

vercel whoami

• If the command fails: tell the user to run vercel login

3. Project linked?

ls .vercel/project.json

• If the file does not exist: tell the user to run vercel link to select a project

---

Step 1: Fetch Logs

By default, vercel logs shows request logs from the last 24 hours for the linked project and current git branch.

Default (last 100 logs for current branch):

vercel logs

Production environment only:

vercel logs --environment production --limit 100

Specific deployment:

vercel logs --deployment <deployment-id-or-url> --limit 100

Stream live runtime logs (up to 5 minutes):

vercel logs --follow

Build logs for a specific deployment:

vercel inspect <deployment-url> --logs

Step 2: Filter

The CLI has native filtering — prefer these over piping through grep.

By log level:

vercel logs --level error
vercel logs --level error --level warning

Valid levels: error, warning, info, fatal

By HTTP status code:

vercel logs --status-code 500
vercel logs --status-code 5xx
vercel logs --status-code 4xx

By source type:

vercel logs --source serverless
vercel logs --source edge-function
vercel logs --source edge-middleware
vercel logs --source static

Can combine multiple: --source serverless --source edge-function

By time range:

vercel logs --since 1h
vercel logs --since 30m
vercel logs --since 2h --until 1h
vercel logs --since 2026-01-15T10:00:00Z

Full-text search:

vercel logs --query "timeout"
vercel logs --query "ECONNREFUSED"

By git branch:

vercel logs --branch main
vercel logs --branch feature-x
vercel logs --no-branch  # all branches

By request ID (trace a specific request):

vercel logs --request-id req_xxxxx

Step 3: JSON Output & Parsing

Use --json to get structured JSON Lines output. Do NOT pipe through jq — instead, parse the JSON output yourself to extract and filter the fields you need.

JSON Lines format:

vercel logs --json --level error --since 1h

Parse the JSON output to extract .message, .level, .statusCode, .duration, and other fields as needed.

Expanded output (full log messages, not truncated):

vercel logs --expand --limit 50

Common Investigations

Recent errors:

vercel logs --level error --since 1h --expand

5xx responses in production:

vercel logs --environment production --status-code 5xx --since 1h

Serverless function timeouts:

vercel logs --source serverless --query "timeout" --since 1h

Edge function / middleware issues:

vercel logs --source edge-function --source edge-middleware --level error

Cold start analysis:

vercel logs --source serverless --json --since 1h

Parse the JSON output and filter for entries where .duration > 3000 to identify slow cold starts.

Memory / payload issues:

vercel logs --query "FUNCTION_PAYLOAD_TOO_LARGE" --since 24h
vercel logs --query "memory" --level error --since 24h

ISR / cache issues:

vercel logs --query "revalidat" --since 1h

Build failures:

vercel inspect <deployment-url> --logs

Step 4: Present Results

Format log output clearly:

• Group by severity (errors first, then warnings, then info)
• Highlight 5xx responses and timeouts
• Show request path, status code, and duration for each invocation
• Calculate summary stats: total requests, error rate, p50/p95 duration if enough data
• If logs are empty or the deployment has no recent activity, say so
• Suggest next steps based on what the logs show

Advanced: Deployment Bisect

To find which deployment introduced a regression:

vercel bisect
vercel bisect --good <known-good-url> --bad <known-bad-url>

This performs a binary search across deployments — very useful for tracking down when an issue was introduced.

Output Enrichment

Get function-level detail for a specific deployment:

vercel inspect <deployment-url>

Shows all serverless functions, edge functions, static assets, regions, runtimes, memory limits, and max durations.

HTTP timing stats for a specific route:

vercel httpstat /api/your-route

Cross-reference with deployment list:

vercel ls --limit 20

$ARGUMENTS

========================================

Status mode — project overview: deployments, domains, env vars, config

Quick dashboard for your Vercel project. Shows project info, deployments, domains, environment variables, and framework details at a glance.

Instructions

Follow these steps exactly in order.

---

Step 0: Prerequisites

Run these checks in order. Stop at the first failure and guide the user.

1. CLI installed?

vercel --version

• If the command fails (non-zero exit code or "command not found"): tell the user to install with npm install -g vercel

2. Authenticated?

vercel whoami

• If the command fails: tell the user to run vercel login

3. Project linked?

ls .vercel/project.json

• If the file does not exist: tell the user to run vercel link to select a project

---

Step 1: Project Overview

vercel project inspect

Also use the Read tool to read .vercel/project.json (skip if it doesn't exist).

Parse and present: project name, project ID, org ID, framework, Node.js version.

Also check for framework configuration using the Read tool:

• Read vercel.json (skip if it doesn't exist)
• Read next.config.js, next.config.mjs, or next.config.ts — check each in order (skip if none exist)

Step 2: Recent Deployments

vercel ls --limit 10

Show the 10 most recent deployments: status, URL, environment (production/preview), age/timestamp, and commit.

Step 3: Inspect Latest Production Deployment

Get the most recent production deployment URL from Step 2 and inspect it:

vercel inspect <production-url>

Parse and present: deployment ID, state, target (production/preview), creator, build duration, regions, routes, serverless function details.

Step 4: Domains

vercel domains ls

List all domains with their configuration status (valid, invalid, pending).

Step 5: Environment Variables

vercel env ls

List variable names and targets (Production, Preview, Development) — never display values. Note any variables that exist only in some environments.

Step 6: Present Dashboard

Format all output as a clean summary:

Vercel Dashboard
═══════════════════════════════════════════════════════
  Project:      [name] ([id])
  Framework:    [Next.js / Remix / Nuxt / Static / etc.]
  Node.js:      [version if detected]
  Region:       [primary region]
═══════════════════════════════════════════════════════

Recent Deployments
┌────────────────────────────┬────────────┬────────────┬──────────┐
│ URL                        │ Status     │ Target     │ When     │
├────────────────────────────┼────────────┼────────────┼──────────┤
│ ...                        │ ...        │ ...        │ ...      │
└────────────────────────────┴────────────┴────────────┴──────────┘

Production Deployment
  URL:        [url]
  State:      [READY / ERROR / BUILDING / QUEUED]
  Created:    [timestamp]
  Build:      [duration]
  Functions:  [count] serverless, [count] edge

Domains
┌──────────────────────────┬────────────┬─────────────────────┐
│ Domain                   │ Status     │ Configuration       │
├──────────────────────────┼────────────┼─────────────────────┤
│ ...                      │ ...        │ ...                 │
└──────────────────────────┴────────────┴─────────────────────┘

Environment Variables: [count per target]
  Production: [count]
  Preview:    [count]
  Development:[count]

========================================

Migration

Consolidated from legacy claudefather skills. Pick the mode based on intent.