Agent Skills: Deploy to Vercel

Deploy to Vercel

Deploy any project to Vercel. Always deploy as preview (not production) unless the user explicitly asks for production.

The goal is to get the user into the best long-term setup: their project linked to Vercel with git-push deploys. Every method below tries to move the user closer to that state.

Step 1: Gather Project State

Run all four checks before deciding which method to use:

# 1. Check for a git remote
git remote get-url origin 2>/dev/null

# 2. Check if locally linked to a Vercel project (either file means linked)
cat .vercel/project.json 2>/dev/null || cat .vercel/repo.json 2>/dev/null

# 3. Check if the Vercel CLI is installed and authenticated
vercel whoami 2>/dev/null

# 4. List available teams (if authenticated)
vercel teams list --format json 2>/dev/null

Team selection

If the user belongs to multiple teams, present all available team slugs as a bulleted list and ask which one to deploy to. Once the user picks a team, proceed immediately to the next step — do not ask for additional confirmation.

Pass the team slug via --scope on all subsequent CLI commands (vercel deploy, vercel link, vercel inspect, etc.):

vercel deploy [path] -y --no-wait --scope <team-slug>

If the project is already linked (.vercel/project.json or .vercel/repo.json exists), the orgId in those files determines the team — no need to ask again. If there is only one team (or just a personal account), skip the prompt and use it directly.

About the .vercel/ directory: A linked project has either:

• .vercel/project.json — created by vercel link (single project linking). Contains projectId and orgId.
• .vercel/repo.json — created by vercel link --repo (repo-based linking). Contains orgId, remoteName, and a projects array mapping directories to Vercel project IDs.

Either file means the project is linked. Check for both.

Do NOT use vercel project inspect, vercel ls, or vercel link to detect state in an unlinked directory — without a .vercel/ config, they will interactively prompt (or with --yes, silently link as a side-effect). Only vercel whoami is safe to run anywhere.

Step 2: Choose a Deploy Method

Linked (.vercel/ exists) + has git remote → Git Push

This is the ideal state. The project is linked and has git integration.

1. Ask the user before pushing. Never push without explicit approval:

   This project is connected to Vercel via git. I can commit and push to
   trigger a deployment. Want me to proceed?
   

2. Commit and push:

   git add .
   git commit -m "deploy: <description of changes>"
   git push
   

   Vercel automatically builds from the push. Non-production branches get preview deployments; the production branch (usually main) gets a production deployment.

3. Retrieve the preview URL. If the CLI is authenticated:

   sleep 5
   vercel ls --format json
   

   The JSON output has a deployments array. Find the latest entry — its url field is the preview URL.

   If the CLI is not authenticated, tell the user to check the Vercel dashboard or the commit status checks on their git provider for the preview URL.

Linked (.vercel/ exists) + no git remote → vercel deploy

The project is linked but there's no git repo. Deploy directly with the CLI.

vercel deploy [path] -y --no-wait

Use --no-wait so the CLI returns immediately with the deployment URL instead of blocking until the build finishes (builds can take a while). Then check on the deployment status with:

vercel inspect <deployment-url>

For production deploys (only if user explicitly asks):

vercel deploy [path] --prod -y --no-wait

Not linked + CLI is authenticated → Link first, then deploy

The CLI is working but the project isn't linked yet. This is the opportunity to get the user into the best state.

1. Ask the user which team to deploy to. Present the team slugs from Step 1 as a bulleted list. If there's only one team (or just a personal account), skip this step.

2. Once a team is selected, proceed directly to linking. Tell the user what will happen but do not ask for separate confirmation:

   Linking this project to <team name> on Vercel. This will create a Vercel
   project to deploy to and enable automatic deployments on future git pushes.
   

3. If a git remote exists, use repo-based linking with the selected team scope:

   vercel link --repo --scope <team-slug>
   

   This reads the git remote URL and matches it to existing Vercel projects that deploy from that repo. It creates .vercel/repo.json. This is much more reliable than vercel link (without --repo), which tries to match by directory name and often fails when the local folder and Vercel project are named differently.

   If there is no git remote, fall back to standard linking:

   vercel link --scope <team-slug>
   

   This prompts the user to select or create a project. It creates .vercel/project.json.

4. Then deploy using the best available method:

   • If a git remote exists → commit and push (see git push method above)
   • If no git remote → vercel deploy [path] -y --no-wait --scope <team-slug>, then vercel inspect <url> to check status

Not linked + CLI not authenticated → Install, auth, link, deploy

The Vercel CLI isn't set up at all.

1. Install the CLI (if not already installed):

   npm install -g vercel
   

2. Authenticate:

   vercel login
   

   The user completes authentication in their browser. If interactive authentication is unavailable or fails, stop and explain that an authenticated Vercel CLI session is required. Do not package or upload the project through another service.

3. Ask which team to deploy to — present team slugs from vercel teams list --format json as a bulleted list. If only one team / personal account, skip. Once selected, proceed immediately.

4. Link the project with the selected team scope (use --repo if a git remote exists, plain vercel link otherwise):

   vercel link --repo --scope <team-slug>   # if git remote exists
   vercel link --scope <team-slug>          # if no git remote
   

5. Deploy using the best available method (git push if remote exists, otherwise vercel deploy -y --no-wait --scope <team-slug>, then vercel inspect <url> to check status).

Authentication unavailable → Stop

Do not deploy without an authenticated Vercel CLI session. Do not run bundled fallback scripts, send the project to an unauthenticated deployment endpoint, or upload an archive through another service.

Tell the user that deployment stopped because Vercel authentication is required. They can run vercel login and retry after authentication succeeds.

Output

Always show the user the deployment URL.

• Git push: Use vercel ls --format json to find the preview URL. If the CLI isn't authenticated, tell the user to check the Vercel dashboard or commit status checks.
• CLI deploy: Show the URL returned by vercel deploy --no-wait. Use vercel inspect <url> to check build status and report it to the user.

Do not curl or fetch the deployed URL to verify it works. Just return the link.

Troubleshooting

Network Access Error

If deployment fails because network access is unavailable, report the failure and stop. Do not route the project through a different deployment endpoint.

CLI Auth Failure

If vercel login or vercel deploy fails with authentication errors, report that an authenticated Vercel CLI session is required and stop.