Deploy To Vercel
Push a local app or site to Vercel as a preview URL while nudging the repo toward git-linked, long-term deploys.
Overview
Deploy to Vercel is an agent skill for the Ship phase that runs a four-check project state ritual and deploys to Vercel—preview by default—with team scope on every CLI step.
Install
npx skills add https://github.com/vercel-labs/agent-skills --skill deploy-to-vercelWhat is this skill?
- Runs four project-state checks (git remote, .vercel link files, CLI auth, teams list) before choosing a deploy path
- Defaults to preview deployments unless the user explicitly asks for production
- Optimizes for linked Vercel projects and git-push deploys as the end state
- Handles multi-team accounts with --scope on link, deploy, and inspect commands
- Maps common user phrases (“deploy my app”, “push this live”, preview links) to a consistent CLI workflow
- 4 project-state checks before choosing a deploy method
Adoption & trust: 67.1k installs on skills.sh; 27.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a build-ready project locally but no reliable, repeatable path to a Vercel preview URL or a properly linked git-deploy setup.
Who is it for?
Solo builders with a working app in a git repo who want preview URLs fast while moving toward standard Vercel git integration.
Skip if: Teams that have not installed or authenticated the Vercel CLI, or workflows that need infra choice, cost modeling, or non-Vercel hosts before any deploy.
When should I use this skill?
User requests deployment actions like "deploy my app", "deploy and give me the link", "push this live", or "create a preview deployment".
What do I get? / Deliverables
You get a preview deployment link (or production only if you asked) with link/auth/remote state clarified and team scope applied consistently across Vercel CLI commands.
- Preview deployment URL
- Documented link/auth/remote state
- Team-scoped Vercel CLI commands
Recommended Skills
Journey fit
Deployment is the canonical Ship moment: taking built code live (or preview-live) with the right project linkage and scope. The launch subphase under Ship covers go-live actions—preview deploys and production only when explicitly requested—rather than pre-ship testing or security review.
How it compares
Use instead of ad-hoc “run vercel” chat steps that skip link state, team scope, and preview-vs-production defaults.
Common Questions / FAQ
Who is deploy-to-vercel for?
Solo and indie developers shipping web apps or sites with the Vercel CLI who want an agent to enforce preview-first deploys and proper project linkage.
When should I use deploy-to-vercel?
Use it in Ship when you say “deploy my app”, “push this live”, or “create a preview deployment”; it also fits late Build when you need a hosted preview to validate integrations before full launch prep.
Is deploy-to-vercel safe to install?
It drives shell, git, network, and authenticated Vercel access—review the Security Audits panel on this Prism page and confirm team scope before production deploys.
SKILL.md
READMESKILL.md - 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: ```bash # 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.): ```bash 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:** ```bash 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: ```bash 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. ```bash 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: ```bash vercel inspect <deployment-url> ``` For production deploys (only if user explicitly ask