# Remove Vercel

Every step is idempotent — safe to re-run. Steps delete the files and config the apply created.

## 1. Remove the container skill

Delete the copied container skill and its per-group session copies:

```bash
rm -rf container/skills/vercel-cli
for session_dir in data/v2-sessions/ag-*; do
  rm -rf "$session_dir/.claude-shared/skills/vercel-cli"
done
```

## 2. Remove the dependency guard test

```bash
rm -f src/vercel-manifest.test.ts
```

## 3. Remove the OneCLI credential

Delete the Vercel secret and strip its id from every agent's assigned list. `set-secrets` replaces the whole list, so read, filter, and write back per agent:

```bash
VERCEL_SECRET_ID=$(onecli secrets list | jq -r '.data[] | select(.name | test("(?i)vercel")) | .id' | head -1)
if [ -n "$VERCEL_SECRET_ID" ]; then
  for agent in $(onecli agents list | jq -r '.data[].id'); do
    REMAINING=$(onecli agents secrets --id "$agent" | jq -r --arg id "$VERCEL_SECRET_ID" '[.data[] | select(. != $id)] | join(",")')
    onecli agents set-secrets --id "$agent" --secret-ids "$REMAINING"
  done
  onecli secrets delete --id "$VERCEL_SECRET_ID"
fi
```

## 4. The Vercel CLI in the container image

Remove the `vercel` entry from `container/cli-tools.json` — this skill added it, and it is
not part of the base image. Then `./container/build.sh` so the image matches the manifest.

## 5. Restart running containers

So sessions stop loading the removed `vercel-cli` skill on next wake:

```bash
docker ps --filter label=nanoclaw-session -q | xargs -r docker stop
```

---
name: add-vercel
description: Add Vercel deployment capability to NanoClaw agents. Installs the Vercel CLI in agent containers and sets up OneCLI credential injection for api.vercel.com. Use when the user wants agents to deploy web applications to Vercel.
---

# Add Vercel

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.

**Principle:** 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).

## Phase 1: Pre-flight

### Check if already applied

Check if the container skill exists:

```bash
test -d container/skills/vercel-cli && echo "INSTALLED" || echo "NOT_INSTALLED"
```

If `INSTALLED`, skip to Phase 3 (Configure Credentials).

### Check prerequisites

Verify OneCLI is working (required for credential injection):

```bash
onecli version 2>/dev/null && echo "ONECLI_OK" || echo "ONECLI_MISSING"
```

If `ONECLI_MISSING`, tell the user to run `/init-onecli` first, then retry `/add-vercel`. Stop here.

## Phase 2: Install Container Skill

Copy the bundled container skill into the container skills directory:

```bash
rsync -a .claude/skills/add-vercel/container-skills/ container/skills/
```

Verify:

```bash
head -5 container/skills/vercel-cli/SKILL.md
```

## Phase 3: Configure Credentials

### Check if Vercel credential already exists

```bash
onecli secrets list 2>/dev/null | grep -i vercel
```

If a Vercel credential already exists, skip to Phase 4.

### Set up Vercel API credential

The agent needs a Vercel personal access token. Tell the user:

> I need your Vercel personal access token. Go to https://vercel.com/account/tokens and create one with these settings:
>
> - **Token name:** `nanoclaw` (or any name you'll recognize)
> - **Scope:** "Full Account" — the agent needs to create projects, deploy, and manage domains
> - **Expiration:** "No expiration" recommended (avoids credential rotation), or pick a date if your security policy requires it
>
> After creating the token, copy it — you'll only see it once.

Once the user provides the token, add it to OneCLI:

```bash
onecli secrets create \
  --name "Vercel API Token" \
  --type generic \
  --value "<TOKEN>" \
  --host-pattern "api.vercel.com" \
  --header-name "Authorization" \
  --value-format "Bearer {value}"
```

Verify:

```bash
onecli secrets list | grep -i vercel
```

### Assign the secret to all agents

OneCLI 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:

```bash
# set-secrets replaces the entire list — read and merge for each agent.
VERCEL_SECRET_ID=$(onecli secrets list | jq -r '.data[] | select(.name | test("(?i)vercel")) | .id' | head -1)
for agent in $(onecli agents list | jq -r '.data[].id'); do
  CURRENT=$(onecli agents secrets --id "$agent" | jq -r '[.data[]] | join(",")')
  MERGED=$(printf '%s' "$CURRENT,$VERCEL_SECRET_ID" | tr ',' '\n' | sort -u | paste -sd ',' -)
  onecli agents set-secrets --id "$agent" --secret-ids "$MERGED"
done
```

## Phase 4: Ensure Vercel CLI in Container Image

The Vercel CLI is not in the agent image by default — this skill is what adds
it. It goes in `container/cli-tools.json` as a json-merge rather than a
Dockerfile edit, which is what keeps the change deterministic and removable.

```bash
grep -q '"vercel"' container/cli-tools.json && echo "PRESENT" || echo "MISSING"
```

If `MISSING`, append the entry, keeping an exact pinned version — the manifest
rejects ranges, so the supply-chain policy still applies:

```json
{ "name": "vercel", "version": "52.2.1" }
```

Then apply it:

```bash
./container/build.sh
```

On an install that builds its own image, that rebuilds it. On one that fetches a
published image, the same command adds Vercel as a single layer on top of the
image already there, so the publisher's patched components underneath are kept —
you are adding a tool, not replacing the runtime. The command says what that does
and does not cover.

If `PRESENT`, the CLI is already in the manifest — skip the rebuild.

## Phase 4b: Copy and Run the Dependency Guard

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:

```bash
cp .claude/skills/add-vercel/vercel-manifest.test.ts src/vercel-manifest.test.ts
pnpm exec vitest run src/vercel-manifest.test.ts
```

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

## Phase 5: Sync Skills to Running Agent Groups

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:

```bash
for session_dir in data/v2-sessions/ag-*; do
  if [ -d "$session_dir/.claude-shared/skills" ]; then
    rsync -a container/skills/ "$session_dir/.claude-shared/skills/"
    echo "Synced skills to: $session_dir"
  fi
done
```

## Phase 6: Restart Running Containers

Stop all running agent containers so they pick up the new skills on next wake:

```bash
docker ps --filter label=nanoclaw-session -q | xargs -r docker stop
```

## Done

The agent can now deploy web applications to Vercel. Key commands:

- `vercel deploy --yes --prod --token placeholder` — deploy to production
- `vercel ls --token placeholder` — list deployments
- `vercel whoami --token placeholder` — check auth

For the full command reference, the agent has the `vercel-cli` container skill loaded automatically.

/**
 * Dependency guard for the Vercel CLI integration point (host tree, vitest).
 *
 * add-vercel installs the `vercel` CLI into the agent image by appending to
 * `container/cli-tools.json`, and drops its container skill into
 * `container/skills/vercel-cli/`. A globally-installed CLI binary is not
 * importable or typed, so neither `tsc` nor a runtime import can catch its
 * removal — only an image build would, and the skill's validate step does not
 * rebuild the image in CI. This structural test stands in for that leg.
 *
 * It checks both halves, because either alone is a broken install: a manifest
 * entry with no skill leaves the agent a binary it was never told about, and a
 * skill with no manifest entry tells the agent to run a command that is not
 * there.
 *
 * Supersedes `vercel-dockerfile.test.ts`, which asserted an `ARG VERCEL_VERSION`
 * / `pnpm install -g vercel@…` pair in the Dockerfile. That shape stopped
 * existing when cli-tools.json took over the global CLIs, so the old guard was
 * asserting against a file that no longer decides anything.
 */
import fs from 'fs';
import path from 'path';

import { describe, it, expect } from 'vitest';

/** Repo root — the dir holding container/, wherever this file is copied to. */
function repoRoot(): string {
  let dir = __dirname;
  for (let i = 0; i < 8; i++) {
    if (fs.existsSync(path.join(dir, 'container', 'cli-tools.json'))) return dir;
    dir = path.dirname(dir);
  }
  throw new Error('container/cli-tools.json not found walking up from ' + __dirname);
}

describe('the Vercel CLI is installed in the agent image', () => {
  const root = repoRoot();
  const manifest = JSON.parse(
    fs.readFileSync(path.join(root, 'container', 'cli-tools.json'), 'utf8'),
  ) as Array<{ name: string; version: string }>;

  it('appears in the CLI manifest', () => {
    expect(manifest.map((t) => t.name)).toContain('vercel');
  });

  it('is pinned to an exact version, so the supply-chain policy still applies', () => {
    const vercel = manifest.find((t) => t.name === 'vercel');
    expect(vercel?.version).toMatch(/^\d+\.\d+\.\d+(?:[-+][0-9A-Za-z.-]+)?$/);
  });

  it('ships its container skill, so the agent knows the CLI is there', () => {
    expect(fs.existsSync(path.join(root, 'container', 'skills', 'vercel-cli', 'SKILL.md'))).toBe(
      true,
    );
  });
});