deploy-to-vercel Checked

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 auth in their browser. If running in a non-interactive environment where login is not possible, skip to the **no-auth fallback** below.

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).

---

### No-Auth Fallback — claude.ai sandbox

**When to use:** Last resort when the CLI can't be installed or authenticated in the claude.ai sandbox. This requires no authentication — it returns a **Preview URL** (live site) and a **Claim URL** (transfer to your Vercel account).

bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh [path]

**Arguments:**

• path - Directory to deploy, or a .tgz file (defaults to current directory)

**Examples:**

# Deploy current directory
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh

# Deploy specific project
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /path/to/project

# Deploy existing tarball
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /path/to/project.tgz

The script auto-detects the framework from package.json, packages the project (excluding node_modules, .git, .env), uploads it, and waits for the build to complete.

**Tell the user:** "Your deployment is ready at [previewUrl]. Claim it at [claimUrl] to manage your deployment."

---

### No-Auth Fallback — Codex sandbox

**When to use:** In the Codex sandbox where the CLI may not be authenticated. Codex runs in a sandboxed environment by default — try the CLI first, and fall back to the deploy script if auth fails.

1. **Check whether the Vercel CLI is installed** (no escalation needed for this check):

   command -v vercel

2. **If vercel is installed**, try deploying with the CLI:

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

3. **If `verce