This skill gives NanoClaw agents the ability to deploy web applications to Vercel. It installs the Vercel CLI in agent containers and configures OneCLI to inject Vercel credentials automatically.
\nPrinciple: Do the work — don't tell the user to do it. Only ask for their input when it genuinely requires manual action (pasting a token).
\nCheck if the container skill exists:
\ntest -d container/skills/vercel-cli && echo \"INSTALLED\" || echo \"NOT_INSTALLED\"\nIf INSTALLED, skip to Phase 3 (Configure Credentials).
Verify OneCLI is working (required for credential injection):
\nonecli version 2>/dev/null && echo \"ONECLI_OK\" || echo \"ONECLI_MISSING\"\nIf ONECLI_MISSING, tell the user to run /init-onecli first, then retry /add-vercel. Stop here.
Copy the bundled container skill into the container skills directory:
\nrsync -a .claude/skills/add-vercel/container-skills/ container/skills/\nVerify:
\nhead -5 container/skills/vercel-cli/SKILL.md\nonecli secrets list 2>/dev/null | grep -i vercel\nIf a Vercel credential already exists, skip to Phase 4.
\nThe agent needs a Vercel personal access token. Tell the user:
\n\n\nI need your Vercel personal access token. Go to https://vercel.com/account/tokens and create one with these settings:
\n\n
\n- Token name:
\nnanoclaw(or any name you'll recognize)- Scope: \"Full Account\" — the agent needs to create projects, deploy, and manage domains
\n- Expiration: \"No expiration\" recommended (avoids credential rotation), or pick a date if your security policy requires it
\nAfter creating the token, copy it — you'll only see it once.
\n
Once the user provides the token, add it to OneCLI:
\nonecli secrets create \\\n --name \"Vercel API Token\" \\\n --type generic \\\n --value \"<TOKEN>\" \\\n --host-pattern \"api.vercel.com\" \\\n --header-name \"Authorization\" \\\n --value-format \"Bearer {value}\"\nVerify:
\nonecli secrets list | grep -i vercel\nOneCLI uses selective secret mode — secrets must be explicitly assigned to each agent. Get the Vercel secret ID from the output above, then assign it to every agent:
\n# set-secrets replaces the entire list — read and merge for each agent.\nVERCEL_SECRET_ID=$(onecli secrets list | jq -r '.data[] | select(.name | test(\"(?i)vercel\")) | .id' | head -1)\nfor agent in $(onecli agents list | jq -r '.data[].id'); do\n CURRENT=$(onecli agents secrets --id \"$agent\" | jq -r '[.data[]] | join(\",\")')\n MERGED=$(printf '%s' \"$CURRENT,$VERCEL_SECRET_ID\" | tr ',' '\\n' | sort -u | paste -sd ',' -)\n onecli agents set-secrets --id \"$agent\" --secret-ids \"$MERGED\"\ndone\nThe Vercel CLI is not in the agent image by default — this skill is what adds\nit. It goes in container/cli-tools.json as a json-merge rather than a\nDockerfile edit, which is what keeps the change deterministic and removable.
grep -q '\"vercel\"' container/cli-tools.json && echo \"PRESENT\" || echo \"MISSING\"\nIf MISSING, append the entry, keeping an exact pinned version — the manifest\nrejects ranges, so the supply-chain policy still applies:
{ \"name\": \"vercel\", \"version\": \"52.2.1\" }\nThen apply it:
\n./container/build.sh\nOn an install that builds its own image, that rebuilds it. On one that fetches a\npublished image, the same command adds Vercel as a single layer on top of the\nimage already there, so the publisher's patched components underneath are kept —\nyou are adding a tool, not replacing the runtime. The command says what that does\nand does not cover.
\nIf PRESENT, the CLI is already in the manifest — skip the rebuild.
The Vercel CLI is a globally-installed binary — not importable or typed — so a structural test guards the install. Copy it into the host test tree and run it:
\ncp .claude/skills/add-vercel/vercel-manifest.test.ts src/vercel-manifest.test.ts\npnpm exec vitest run src/vercel-manifest.test.ts\nThe test asserts both halves of the install: a pinned vercel entry in container/cli-tools.json, and the container skill at container/skills/vercel-cli/. Either alone is a broken install — a manifest entry with no skill leaves the agent a binary nobody told it about, and a skill with no entry tells it to run a command that is not there.
Container skills are copied once at group creation and not auto-synced. After installing or updating a container skill, sync it to all existing agent groups:
\nfor session_dir in data/v2-sessions/ag-*; do\n if [ -d \"$session_dir/.claude-shared/skills\" ]; then\n rsync -a container/skills/ \"$session_dir/.claude-shared/skills/\"\n echo \"Synced skills to: $session_dir\"\n fi\ndone\nStop all running agent containers so they pick up the new skills on next wake:
\ndocker ps --filter label=nanoclaw-session -q | xargs -r docker stop\nThe agent can now deploy web applications to Vercel. Key commands:
\nvercel deploy --yes --prod --token placeholder — deploy to productionvercel ls --token placeholder — list deploymentsvercel whoami --token placeholder — check authFor the full command reference, the agent has the vercel-cli container skill loaded automatically.