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.