Vercel Deploy

Deploy and manage Vercel projects. Use when deploying applications to Vercel, managing environment variables, checking deployment status, viewing logs, or performing Vercel operations. Supports production and preview deployments. Practical infrastructure operations - no "AI will build your app" magic.

Security Scan

The skill's files mostly match a Vercel deployment helper, but there are inconsistencies and a few security/practical concerns (undeclared token in registry metadata, missing referenced script, and token-handling that can leak credentials).

Purpose & Capability

Name/description and the included scripts (deploy/env/status) coherently implement a Vercel deployment helper. However the registry metadata declares no required environment variables or primary credential while the SKILL.md and all scripts require VERCEL_TOKEN — a metadata vs implementation mismatch. The SKILL.md/README also reference a scripts/vercel_logs.sh that is not present in the file manifest, which is an operational inconsistency.

Instruction Scope

Runtime instructions are narrowly scoped to Vercel operations (deployments, env vars, status/logs) and do not request unrelated data. But instructions and scripts recommend persisting VERCEL_TOKEN in shell startup files and the scripts pass the token using the --token CLI flag. Passing tokens on the command line can expose them via process lists on multi-user systems; persisting in ~/.bashrc also increases risk if the machine is shared or backed up to remote storage.

Install Mechanism

No install spec is provided (instruction-only), which minimizes install-time risk. The scripts invoke npx to run the Vercel CLI; npx will fetch packages from the npm registry on first run, which is expected for a CLI-based deployer but still means remote code will be executed at runtime. There are no downloads from arbitrary URLs or other high-risk install behaviors.

Credentials

Only one credential is actually required (VERCEL_TOKEN), which is proportionate for a Vercel deploy tool. However the registry metadata does not declare this requirement (incoherent). Also the token handling (CLI flag + encouraging echo into .bashrc) increases the chance of accidental exposure; the skill should explicitly document safer alternatives (use project-scoped tokens, avoid command-line args, prefer ephemeral CI secrets or OS-level secret stores).

Persistence & Privilege

The skill is not marked always:true and does not request system-wide privileges or modify other skills' configurations. The documentation suggests user actions to persist the token in shell profiles (which would be a user-initiated change), but the skill itself does not claim elevated or permanent privileges.

What to consider before installing

This skill appears to implement legitimate Vercel deployment helpers, but review a few points before installing: - The code expects VERCEL_TOKEN but the registry metadata does not declare it — assume you must provide a Vercel token. Prefer project-scoped tokens and rotate them regularly. - The scripts pass the token via the --token command-line flag and README suggests echoing the token into ~/.bashrc. Both approaches risk exposing the token (process lists, backups). Consider editing the scripts to rely on the VERCEL_TOKEN environment variable without passing it as a CLI argument, or store the token in a secure secret manager. - The SKILL.md/README reference scripts/vercel_logs.sh, but that file is not present. Expect runtime errors if an agent attempts to run log commands as documented. - npx will fetch and run the Vercel CLI from npm on first use — that is expected, but be aware it executes remote code. If you plan to install: inspect the three included scripts locally, remove the CLI --token argument if you prefer env-only usage, and run in a controlled environment (non-shared machine or ephemeral CI) until you're comfortable. If you need higher assurance, ask the author for corrected registry metadata and the missing vercel_logs.sh, or adapt the scripts to avoid exposing the token on the command line.

Vercel Deployment & Management

Deploy and manage Vercel projects. No "AI will build your app" nonsense - just practical Vercel operations.

Configuration

Vercel Setup

Get your token:

1. Go to https://vercel.com/account/tokens
2. Create token (name it "OpenClaw")
3. Set in environment:

export VERCEL_TOKEN="your-token-here"

Or store in .env:

VERCEL_TOKEN=your-token-here

Vercel Operations

Deploy Project

# Deploy to preview
scripts/vercel_deploy.sh --project bountylock --preview

# Deploy to production
scripts/vercel_deploy.sh --project bountylock --production

Manage Environment Variables

# List env vars
scripts/vercel_env.sh --project bountylock --list

# Set env var
scripts/vercel_env.sh --project bountylock --set \
  --key NEXT_PUBLIC_RPC_URL \
  --value "https://sepolia.base.org" \
  --env production

# Delete env var
scripts/vercel_env.sh --project bountylock --delete \
  --key OLD_VAR \
  --env production

Check Deployment Status

# Get latest deployment
scripts/vercel_status.sh --project bountylock

# Get specific deployment
scripts/vercel_status.sh --deployment dpl_abc123

View Logs

# Get deployment logs
scripts/vercel_logs.sh --deployment dpl_abc123

# Get runtime logs
scripts/vercel_logs.sh --project bountylock --function api/bounties

Common Workflows

Initial Testnet Deployment

1. Set environment variables:

# Contract addresses (after deploying to Sepolia)
scripts/vercel_env.sh --project bountylock --set \
  --key NEXT_PUBLIC_CONTRACT_ADDRESS \
  --value "0x..." \
  --env production

# RPC URL
scripts/vercel_env.sh --project bountylock --set \
  --key NEXT_PUBLIC_RPC_URL \
  --value "https://sepolia.base.org" \
  --env production

# Chain ID
scripts/vercel_env.sh --project bountylock --set \
  --key NEXT_PUBLIC_CHAIN_ID \
  --value "84532" \
  --env production

2. Deploy:

scripts/vercel_deploy.sh --project bountylock --production

3. Check status:

scripts/vercel_status.sh --project bountylock

Update Environment Variables

# Update contract address after redeployment
scripts/vercel_env.sh --project bountylock --set \
  --key NEXT_PUBLIC_CONTRACT_ADDRESS \
  --value "0xNEW_ADDRESS" \
  --env production

# Trigger new deployment to use updated vars
scripts/vercel_deploy.sh --project bountylock --production

Debug Deployment Issues

# Get latest deployment info
scripts/vercel_status.sh --project bountylock

# Get build logs
scripts/vercel_logs.sh --deployment dpl_abc123

# Check environment variables
scripts/vercel_env.sh --project bountylock --list

Security Best Practices

1. Token Scope: Use project-scoped tokens when possible
2. Rotation: Rotate tokens periodically
3. Audit: Review deployment logs regularly
4. Secrets: Never commit tokens to git

Troubleshooting

"Authentication failed"

• Check token is set correctly
• Verify token hasn't expired

"Project not found"

• Verify project name matches Vercel project
• Check account has access to project

"Deployment failed"

• Check build logs: scripts/vercel_logs.sh --deployment dpl_xxx
• Verify environment variables are set correctly
• Check for build errors in code

Reference Files

• Vercel API Reference: See vercel-api.md for complete API documentation
• Deployment Patterns: See deployment-patterns.md for common deployment workflows