$npx -y skills add vercel-labs/agent-skills --skill deploy-to-vercelDeploy applications and websites to Vercel. Use when the user requests deployment actions like "deploy my app", "deploy and give me the link", "push this live", or "create a preview deployment".
| 1 | # Deploy to Vercel |
| 2 | |
| 3 | Deploy any project to Vercel. **Always deploy as preview** (not production) unless the user explicitly asks for production. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | ## Step 1: Gather Project State |
| 8 | |
| 9 | Run all four checks before deciding which method to use: |
| 10 | |
| 11 | ```bash |
| 12 | # 1. Check for a git remote |
| 13 | git remote get-url origin 2>/dev/null |
| 14 | |
| 15 | # 2. Check if locally linked to a Vercel project (either file means linked) |
| 16 | cat .vercel/project.json 2>/dev/null || cat .vercel/repo.json 2>/dev/null |
| 17 | |
| 18 | # 3. Check if the Vercel CLI is installed and authenticated |
| 19 | vercel whoami 2>/dev/null |
| 20 | |
| 21 | # 4. List available teams (if authenticated) |
| 22 | vercel teams list --format json 2>/dev/null |
| 23 | ``` |
| 24 | |
| 25 | ### Team selection |
| 26 | |
| 27 | 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. |
| 28 | |
| 29 | Pass the team slug via `--scope` on all subsequent CLI commands (`vercel deploy`, `vercel link`, `vercel inspect`, etc.): |
| 30 | |
| 31 | ```bash |
| 32 | vercel deploy [path] -y --no-wait --scope <team-slug> |
| 33 | ``` |
| 34 | |
| 35 | 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. |
| 36 | |
| 37 | **About the `.vercel/` directory:** A linked project has either: |
| 38 | - `.vercel/project.json` — created by `vercel link` (single project linking). Contains `projectId` and `orgId`. |
| 39 | - `.vercel/repo.json` — created by `vercel link --repo` (repo-based linking). Contains `orgId`, `remoteName`, and a `projects` array mapping directories to Vercel project IDs. |
| 40 | |
| 41 | Either file means the project is linked. Check for both. |
| 42 | |
| 43 | **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. |
| 44 | |
| 45 | ## Step 2: Choose a Deploy Method |
| 46 | |
| 47 | ### Linked (`.vercel/` exists) + has git remote → Git Push |
| 48 | |
| 49 | This is the ideal state. The project is linked and has git integration. |
| 50 | |
| 51 | 1. **Ask the user before pushing.** Never push without explicit approval: |
| 52 | ``` |
| 53 | This project is connected to Vercel via git. I can commit and push to |
| 54 | trigger a deployment. Want me to proceed? |
| 55 | ``` |
| 56 | |
| 57 | 2. **Commit and push:** |
| 58 | ```bash |
| 59 | git add . |
| 60 | git commit -m "deploy: <description of changes>" |
| 61 | git push |
| 62 | ``` |
| 63 | Vercel automatically builds from the push. Non-production branches get preview deployments; the production branch (usually `main`) gets a production deployment. |
| 64 | |
| 65 | 3. **Retrieve the preview URL.** If the CLI is authenticated: |
| 66 | ```bash |
| 67 | sleep 5 |
| 68 | vercel ls --format json |
| 69 | ``` |
| 70 | The JSON output has a `deployments` array. Find the latest entry — its `url` field is the preview URL. |
| 71 | |
| 72 | 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. |
| 73 | |
| 74 | --- |
| 75 | |
| 76 | ### Linked (`.vercel/` exists) + no git remote → `vercel deploy` |
| 77 | |
| 78 | The project is linked but there's no git repo. Deploy directly with the CLI. |
| 79 | |
| 80 | ```bash |
| 81 | vercel deploy [path] -y --no-wait |
| 82 | ``` |
| 83 | |
| 84 | 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: |
| 85 | |
| 86 | ```bash |
| 87 | vercel inspect <deployment-url> |
| 88 | ``` |
| 89 | |
| 90 | For production deploys (only if user explicitly asks): |
| 91 | ```bash |
| 92 | vercel deploy [path] --prod -y --no-wait |
| 93 | ``` |
| 94 | |
| 95 | --- |
| 96 | |
| 97 | ### Not linked + CLI is authenticated → Link first, then deploy |
| 98 | |
| 99 | The CLI is working but the project isn't linked yet. This is the opportunity to get the user into the best state. |
| 100 | |
| 101 | 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. |
| 102 | |
| 103 | 2. **Once a team is selected, proceed directly to linking.** Tell the user what will happen but do not ask for separate confirmation: |
| 104 | ``` |
| 105 | Linking this project to <team name> on Vercel. This will create a Vercel |
| 106 | project to deploy to and enable automatic deployments on future git pushes. |
| 107 | ``` |
| 108 | |
| 109 | 3. **If a git remote exists**, use repo-based linking with the selected team scope: |
| 110 | ```bash |
| 111 | vercel link --repo --scope <team-slug> |
| 112 | ``` |
| 113 | This reads the git remote URL and matches it to existing Vercel projects that deploy from that repo. It creates `.vercel/repo.json`. T |