vercel-cli-with-tokens
Deploy and manage projects on Vercel using token-based authentication. Use when working with Vercel CLI using access tokens rather than interactive login — e.g. "deploy to vercel", "set up vercel", "add environment variables to vercel".
What this skill does
# Vercel CLI with Tokens Deploy and manage projects on Vercel using the CLI with token-based authentication, without relying on `vercel login`. ## Step 1: Locate the Vercel Token Before running any Vercel CLI commands, identify where the token is coming from. Work through these scenarios in order: ### A) `VERCEL_TOKEN` is already set in the environment ```bash printenv VERCEL_TOKEN ``` If this returns a value, you're ready. Skip to Step 2. ### B) Token is in a `.env` file under `VERCEL_TOKEN` ```bash grep '^VERCEL_TOKEN=' .env 2>/dev/null ``` If found, export it: ```bash export VERCEL_TOKEN=$(grep '^VERCEL_TOKEN=' .env | cut -d= -f2-) ``` ### C) Token is in a `.env` file under a different name Look for any variable that looks like a Vercel token (Vercel tokens typically start with `vca_`): ```bash grep -i 'vercel' .env 2>/dev/null ``` Inspect the output to identify which variable holds the token, then export it as `VERCEL_TOKEN`: ```bash export VERCEL_TOKEN=$(grep '^<VARIABLE_NAME>=' .env | cut -d= -f2-) ``` ### D) No token found — ask the user If none of the above yield a token, ask the user to provide one. They can create a Vercel access token at vercel.com/account/tokens. --- **Important:** Once `VERCEL_TOKEN` is exported as an environment variable, the Vercel CLI reads it natively — **do not pass it as a `--token` flag**. Putting secrets in command-line arguments exposes them in shell history and process listings. ```bash # Bad — token visible in shell history and process listings vercel deploy --token "vca_abc123" # Good — CLI reads VERCEL_TOKEN from the environment export VERCEL_TOKEN="vca_abc123" vercel deploy ``` ## Step 2: Locate the Project and Team Similarly, check for the project ID and team scope. These let the CLI target the right project without needing `vercel link`. ```bash # Check environment printenv VERCEL_PROJECT_ID printenv VERCEL_ORG_ID # Or check .env grep -i 'vercel' .env 2>/dev/null ``` **If you have a project URL** (e.g. `https://vercel.com/my-team/my-project`), extract the team slug: ```bash # e.g. "my-team" from "https://vercel.com/my-team/my-project" echo "$PROJECT_URL" | sed 's|https://vercel.com/||' | cut -d/ -f1 ``` **If you have both `VERCEL_ORG_ID` and `VERCEL_PROJECT_ID` in your environment**, export them — the CLI will use these automatically and skip any `.vercel/` directory: ```bash export VERCEL_ORG_ID="<org-id>" export VERCEL_PROJECT_ID="<project-id>" ``` Note: `VERCEL_ORG_ID` and `VERCEL_PROJECT_ID` must be set together — setting only one causes an error. ## CLI Setup Ensure the Vercel CLI is installed: ```bash npm install -g vercel vercel --version ``` ## Deploying a Project Always deploy as **preview** unless the user explicitly requests production. Choose a method based on what you have available. ### Quick Deploy (have project ID — no linking needed) When `VERCEL_TOKEN` and `VERCEL_PROJECT_ID` are set in the environment, deploy directly: ```bash vercel deploy -y --no-wait ``` With a team scope (either via `VERCEL_ORG_ID` or `--scope`): ```bash vercel deploy --scope <team-slug> -y --no-wait ``` Production (only when explicitly requested): ```bash vercel deploy --prod --scope <team-slug> -y --no-wait ``` Check status: ```bash vercel inspect <deployment-url> ``` ### Full Deploy Flow (no project ID — need to link) Use this when you have a token and team but no pre-existing project ID. #### Check project state first ```bash # Does the project have a git remote? git remote get-url origin 2>/dev/null # Is it already linked to a Vercel project? cat .vercel/project.json 2>/dev/null || cat .vercel/repo.json 2>/dev/null ``` #### Link the project **With git remote (preferred):** ```bash vercel link --repo --scope <team-slug> -y ``` Reads the git remote and connects to the matching Vercel project. Creates `.vercel/repo.json`. More reliable than plain `vercel link`, which matches by directory name. **Without git remote:** ```bash vercel link --scope <team-slug> -y ``` Creates `.vercel/project.json`. **Link to a specific project by name:** ```bash vercel link --project <project-name> --scope <team-slug> -y ``` If the project is already linked, check `orgId` in `.vercel/project.json` or `.vercel/repo.json` to verify it matches the intended team. #### Deploy after linking **A) Git Push Deploy — has git remote (preferred)** Git pushes trigger automatic Vercel deployments. 1. **Ask the user before pushing.** Never push without explicit approval. 2. Commit and push: ```bash git add . git commit -m "deploy: <description of changes>" git push ``` 3. Vercel builds automatically. Non-production branches get preview deployments. 4. Retrieve the deployment URL: ```bash sleep 5 vercel ls --format json --scope <team-slug> ``` Find the latest entry in the `deployments` array. **B) CLI Deploy — no git remote** ```bash vercel deploy --scope <team-slug> -y --no-wait ``` Check status: ```bash vercel inspect <deployment-url> ``` ### Deploying from a Remote Repository (code not cloned locally) 1. Clone the repository: ```bash git clone <repo-url> cd <repo-name> ``` 2. Link to Vercel: ```bash vercel link --repo --scope <team-slug> -y ``` 3. Deploy via git push (if you have push access) or CLI deploy. ### About `.vercel/` Directory A linked project has either: - `.vercel/project.json` — from `vercel link`. Contains `projectId` and `orgId`. - `.vercel/repo.json` — from `vercel link --repo`. Contains `orgId`, `remoteName`, and a `projects` map. Not needed when `VERCEL_ORG_ID` + `VERCEL_PROJECT_ID` are both set in the environment. **Do NOT** run `vercel ls`, `vercel project inspect`, or `vercel link` in an unlinked directory to detect state — they will interactively prompt or silently link as a side-effect. Only `vercel whoami` is safe to run anywhere. ## Managing Environment Variables ```bash # Set for all environments echo "value" | vercel env add VAR_NAME --scope <team-slug> # Set for a specific environment (production, preview, development) echo "value" | vercel env add VAR_NAME production --scope <team-slug> # List environment variables vercel env ls --scope <team-slug> # Pull env vars to local .env file vercel env pull --scope <team-slug> # Remove a variable vercel env rm VAR_NAME --scope <team-slug> -y ``` ## Inspecting Deployments ```bash # List recent deployments vercel ls --format json --scope <team-slug> # Inspect a specific deployment vercel inspect <deployment-url> # View build logs vercel logs <deployment-url> ``` ## Managing Domains ```bash # List domains vercel domains ls --scope <team-slug> # Add a domain to the project vercel domains add <domain> --scope <team-slug> ``` ## Working Agreement - **Never pass `VERCEL_TOKEN` as a `--token` flag.** Export it as an environment variable and let the CLI read it natively. - **Check the environment for tokens before asking the user.** Look in the current env and `.env` files first. - **Default to preview deployments.** Only deploy to production when explicitly asked. - **Ask before pushing to git.** Never push commits without the user's approval. - **Do not read or modify `.vercel/` files directly.** The CLI manages this directory. - **Do not curl/fetch deployed URLs to verify.** Just return the link to the user. - **Use `--format json`** when structured output will help with follow-up steps. - **Use `-y`** on commands that prompt for confirmation to avoid interactive blocking. ## Troubleshooting ### Token not found Check the environment and any `.env` files present: ```bash printenv | grep -i vercel grep -i vercel .env 2>/dev/null ``` ### Authentication error If the CLI fails with `Authentication required`: - The token may be expired or invalid. - Verify: `vercel whoami` (uses `VERCEL_TOKEN` from environment). - Ask the user for a fresh token. ### Wrong team Verify the scope is correct: ```bash vercel whoami --scope <team-slug> ``` ### B
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.