Vercel Deploy
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is a legitimate Vercel operations skill, but it can change production deployments and environment variables with weak safeguards and may expose secret values in output.
Review commands before letting the agent run them, especially production deployments and environment-variable deletion. Use a project-scoped Vercel token, avoid storing it permanently unless necessary, do not enter secret env values until the script masks output, and consider pinning the Vercel CLI and adding confirmations.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Secrets entered as Vercel environment variables could be revealed to anyone who can see the tool output or logs.
The helper prints the full environment-variable value before setting it in Vercel. Environment variables can contain secrets such as API keys, database URLs, or tokens, so this can expose sensitive values in terminal output or agent transcripts.
echo "✏️ Setting $KEY=$VALUE (env: $ENV)"
Mask values in output, show only the variable name and environment, and require explicit user approval before handling secret values.
An agent could remove a production or preview environment variable immediately once this path is invoked, potentially breaking deployments.
The delete path uses Vercel's non-interactive confirmation flag and has no local confirmation prompt, despite modifying remote project configuration.
npx vercel env rm "$KEY" "$ENV" --token "$VERCEL_TOKEN" "$PROJECT" --yes
Remove --yes for destructive operations or add an explicit confirmation step that names the project, key, and environment before deletion.
The agent could deploy the wrong local directory or Vercel-linked project while appearing to deploy the named project.
The script requires a --project argument, but the deployment command does not include or validate $PROJECT. With --yes, the actual deployment target depends on the current directory and Vercel linkage rather than the user-supplied project name.
CMD="npx vercel --token $VERCEL_TOKEN --yes"
Validate the working directory and linked Vercel project before deployment, include the target project in the command where supported, and display the resolved target before proceeding.
Deployments depend on the Vercel CLI package resolved at runtime, which can affect reproducibility and supply-chain review.
The skill runs the Vercel CLI through npx without a pinned version or install declaration. This is expected for a Vercel CLI helper, but it may execute runtime code from npm depending on the user's environment.
CMD="npx vercel --token $VERCEL_TOKEN --yes"
Declare the npx/Node requirement and pin or document the expected Vercel CLI version.
Users may overestimate the credential-safety and approval safeguards provided by the skill.
The README recommends persisting the token in a shell startup file while also saying tokens are not stored, and it claims destructive approval even though the provided env-delete script auto-confirms with --yes.
echo 'export VERCEL_TOKEN="vtk_xxx..."' >> ~/.bashrc ... Tokens are passed via environment variables (not stored) ... Destructive operations require approval
Align the documentation with the actual behavior: state when tokens are persisted, warn about command/output exposure, and accurately describe which operations are auto-confirmed.
