@vellumai/assistant 0.4.43 → 0.4.45

package/src/config/bundled-skills/twitter/SKILL.md

@@ -1,319 +0,0 @@
----
-name: twitter
-description: Read and post on X (formerly Twitter) via OAuth or browser session
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"𝕏","vellum":{"display-name":"X","user-invocable":true}}
----
-
-You are an X (formerly Twitter) assistant. Use the `bash` tool to run `assistant x`, `assistant config`, and `assistant oauth` CLI commands.
-
-## Connection Options
-
-There are three supported ways to connect to X. Choose whichever fits the user's situation.
-
-### Managed mode (platform-hosted credentials)
-
-When `twitter.integrationMode` is set to `managed`, the platform holds the OAuth credentials and proxies Twitter API calls on behalf of the assistant. No local OAuth setup or browser session is needed.
-
-- Supports: **post** and **reply** (routed through the platform proxy)
-- Read-only operations still use the browser path when available.
-- Prerequisites: The assistant must be registered with the platform (`PLATFORM_ASSISTANT_ID`), have an API key (`credential:vellum:assistant_api_key`), and the assistant owner must have connected their Twitter account on the platform.
-- The strategy is automatically set to `managed` when `integrationMode` is `managed` and prerequisites are satisfied.
-
-**Error scenarios in managed mode:**
-- *"Assistant not bootstrapped"* — The assistant API key is missing. Run setup.
-- *"Local assistant not registered with platform"* — `PLATFORM_ASSISTANT_ID` is not set.
-- *"Connect Twitter in Settings as the assistant owner"* — The owner hasn't connected their X account on the platform yet.
-- *"Sign in as the assistant owner"* — The current user is not the assistant owner.
-- *"Reconnect Twitter or retry"* — The platform's OAuth token may have expired. Reconnect on the platform.
-
-**Architecture notes for managed mode:**
-
-- **Assistant hosting mode and Twitter credential mode are separate concepts.** An assistant can be self-hosted (local daemon) yet use managed Twitter credentials, or platform-hosted yet use local BYO OAuth. The `twitter.integrationMode` config controls credential mode; the assistant's hosting mode is determined by its lockfile entry.
-- **Managed Twitter is bound to the assistant owner.** Only the owner of the assistant (as determined by the platform) can connect or disconnect the Twitter account. Non-owner users receive a `403` with an `owner_only` or `owner_credential_required` error code.
-- **Connect/disconnect/status uses desktop session authentication.** The macOS Settings UI calls the platform's Twitter OAuth endpoints using the user's `X-Session-Token` header (obtained during managed sign-in via WorkOS). This authenticates the human user, not the assistant.
-- **Actual Twitter API calls use assistant-level API key authentication.** At runtime, the proxy client sends `Authorization: Api-Key {assistant_api_key}` — it never includes user-level session tokens or OAuth tokens. This ensures the assistant's identity is what the platform uses for token lookup and rate limiting.
-- **The platform proxy handles token storage and refresh.** OAuth tokens are stored server-side by the platform. The assistant never sees or stores the Twitter OAuth access/refresh tokens in managed mode. Token refresh is handled transparently by the proxy.
-- **The daemon auth handler never starts local OAuth in managed mode.** When `integrationMode` is `managed`, `handleTwitterAuthStart` returns a managed-specific error code (`managed_auth_via_platform` or `managed_missing_api_key`) and never calls `orchestrateOAuthConnect`. This is a critical guardrail to prevent credential confusion.
-
-### OAuth (recommended with X developer credentials)
-
-OAuth uses the official X API v2. It is the most reliable connection method and does not depend on browser sessions.
-
-- Supports: **post** and **reply**
-- Read-only operations (timeline, search, home, bookmarks, notifications, likes, followers, following, media) always use the browser path directly, regardless of the strategy setting.
-- Setup: Collect the OAuth Client ID (and optional Client Secret) from the user in chat using `credential_store` with `action: "prompt"` (canonical field names: `client_id`, `client_secret`), then initiate the `twitter_auth_start` flow. See the **First-Use Decision Flow** for the full sequence.
-- Set the strategy: `assistant config set twitter.operationStrategy oauth`
-
-### Browser session (no developer credentials needed)
-
-The browser path is quick to start and useful when the user does not have X developer app credentials. It captures auth cookies from Chrome and uses them to interact with X. Chrome management uses `assistant browser chrome launch` and `assistant browser chrome minimize` CLI commands internally.
-
-- Supports: **all operations** (post, reply, timeline, search, home, bookmarks, notifications, likes, followers, following, media)
-- Setup: Run `assistant x refresh` to open Chrome and capture session cookies automatically.
-- Set the strategy: `assistant config set twitter.operationStrategy browser`
-- **Session storage**: Session cookies are stored in the encrypted credential store under the key `twitter:session:cookies`. You can inspect the stored session with `assistant credentials inspect twitter:session:cookies`.
-
-### Auto mode (default)
-
-When the strategy is `auto` (the default), the router tries OAuth first for supported operations if credentials are available, then falls back to the browser path. This gives the best of both worlds without requiring manual switching.
-
-- Set auto mode: `assistant config set twitter.operationStrategy auto`
-
-## First-Use Decision Flow
-
-When the user triggers a Twitter operation and no strategy has been configured yet, follow these steps:
-
-1. **Check current status:**
-
-   ```bash
-   # Check strategy
-   assistant config get twitter.operationStrategy
-
-   # Check if OAuth token is available
-   assistant oauth token twitter --json
-
-   # Check browser session
-   assistant x status --json
-   ```
-
-   If the strategy is not set, the user has not yet chosen a strategy and should be guided through setup.
-
-2. **Present both options with trade-offs:**
-   - **OAuth**: Most reliable and official. Requires X developer app credentials (OAuth Client ID and optional Client Secret). Supports posting and replying. Set up right here in the chat.
-   - **Browser session**: Quick to start, no developer credentials needed. Supports all operations including reading timelines and searching. Set up with `assistant x refresh`.
-
-3. **Ask the user which they prefer.** Do not choose for them.
-
-4. **Execute setup for the chosen path:**
-   - If OAuth: Collect the credentials in-chat using the secure credential prompt, then connect. Follow the **OAuth Setup Sequence** below.
-   - If browser: Run `assistant x refresh` to capture session cookies from Chrome.
-
-### OAuth Setup Sequence
-
-When the user chooses OAuth, collect their X developer credentials conversationally using the secure UI. The OAuth flow delegates to the generic connect orchestrator, which resolves the Twitter provider profile, computes scopes via policy, opens the X authorization page in the user's browser, verifies the user's identity, and stores tokens. The orchestrator also manages stale refresh-token cleanup and enforces integration-mode guards.
-
-1. **Collect the Client ID securely:**
-   Call `credential_store` with `action: "prompt"`, `service: "integration:twitter"`, `field: "client_id"`, `label: "X (Twitter) OAuth Client ID"`, `description: "Enter the Client ID from your X Developer App"`, and `placeholder: "your-client-id"`.
-
-2. **Collect the Client Secret (if applicable):**
-   Ask the user if their X app uses a confidential client (has a Client Secret). If yes, call `credential_store` with `action: "prompt"`, `service: "integration:twitter"`, `field: "client_secret"`, `label: "X (Twitter) OAuth Client Secret"`, `description: "Enter the Client Secret from your X Developer App (leave blank if using a public client)"`, and `placeholder: "your-client-secret"`.
-
-3. **Initiate the OAuth flow:**
-   Trigger the Twitter auth start flow. The connect orchestrator resolves the Twitter provider profile, computes scopes via policy, opens the X authorization page in the user's browser, verifies the user's identity, and stores tokens. Wait for the auth result.
-
-4. **Confirm success:**
-   Tell the user: "Great, your X account is connected! You can always update these credentials from the Settings page."
-
-5. **Set the preferred strategy:**
-   ```bash
-   assistant config set twitter.operationStrategy <oauth|browser|auto>
-   ```
-
-## Failure Recovery Flow
-
-When a Twitter operation fails, follow these steps:
-
-1. **Detect the failure type from the error output:**
-   - `session_expired` or `SessionExpiredError` — the browser session cookies have expired.
-   - `OAuth is not configured` — the user chose OAuth but credentials are not set up.
-   - `Twitter API error (401)` — OAuth token may be expired or revoked.
-   - `UnsupportedOAuthOperationError` — the requested write operation is not available via OAuth.
-   - `Cannot connect to assistant` — the Vellum assistant is not running.
-   - `proxyErrorCode: "owner_credential_required"` — managed mode: the assistant owner has not connected their X account on the platform.
-   - `proxyErrorCode: "owner_only"` — managed mode: the current user is not the assistant owner.
-   - `proxyErrorCode: "auth_failure"` or `"upstream_failure"` — managed mode: platform token issue, reconnect Twitter on the platform.
-   - `proxyErrorCode: "missing_assistant_api_key"` — managed mode: the assistant is not bootstrapped.
-   - `proxyErrorCode: "missing_platform_assistant_id"` — managed mode: the assistant is not registered with the platform.
-
-2. **Explain the likely cause clearly** to the user.
-
-3. **Suggest trying the other path as an alternative:**
-   - If the browser session expired: suggest setting up OAuth for post/reply operations, or refresh the browser session with `assistant x refresh`.
-   - If OAuth failed or is not configured: suggest using the browser path with `assistant config set twitter.operationStrategy browser` and `assistant x refresh`.
-   - If the operation is unsupported via OAuth: explain that this write operation is not yet supported via OAuth, and suggest using the browser path with `assistant config set twitter.operationStrategy browser`.
-   - If managed mode failed with a credential or ownership error: explain the specific issue and guide the user to resolve it on the platform (connect Twitter, sign in as owner, etc.).
-
-4. **Offer concrete steps to switch:**
-
-   ```bash
-   # Switch to the other strategy
-   assistant config set twitter.operationStrategy <oauth|browser|auto>
-
-   # If switching to browser, refresh the session
-   assistant x refresh
-   ```
-
-## Strategy Management Commands
-
-```bash
-# Check current strategy
-assistant config get twitter.operationStrategy
-
-# Set strategy to OAuth, browser, or auto
-assistant config set twitter.operationStrategy oauth
-assistant config set twitter.operationStrategy browser
-assistant config set twitter.operationStrategy auto
-
-# Check full status (session, OAuth, and strategy info)
-assistant x status --json
-```
-
-## Posting
-
-Before posting, check the integration mode and fetch the current strategy:
-
-```bash
-# 1. Check integration mode
-MODE=$(assistant config get twitter.integrationMode)
-
-# 2. Get the configured strategy
-STRATEGY=$(assistant config get twitter.operationStrategy)
-# If not set, default to "auto"
-```
-
-Then post based on the mode and strategy:
-
-```bash
-# Managed mode — route through platform proxy (no local token needed):
-assistant x post "The post text here" --strategy managed
-
-# With OAuth token (strategy is oauth or auto):
-TOKEN=$(assistant oauth token twitter)
-assistant x post "The post text here" --strategy "$STRATEGY" --oauth-token "$TOKEN"
-
-# With browser-only strategy:
-assistant x post "The post text here" --strategy browser
-```
-
-When `twitter.integrationMode` is `managed`, always use `--strategy managed`. The platform proxy handles authentication.
-
-Returns JSON with `ok`, `tweetId`, `text`, `url`, and `pathUsed` fields. Share the URL with the user so they can verify the post. For managed mode errors, the response includes `proxyErrorCode` and `retryable` fields.
-
-## Replying
-
-Same setup as posting — check integration mode and fetch strategy first, then:
-
-```bash
-# Managed mode:
-assistant x reply <tweetUrl> "The reply text here" --strategy managed
-
-# Local OAuth or auto:
-assistant x reply <tweetUrl> "The reply text here" --strategy "$STRATEGY" --oauth-token "$TOKEN"
-```
-
-The first argument is a tweet URL (e.g. `https://x.com/user/status/123456`) or a bare tweet ID.
-
-## Reading
-
-Read-only operations always use the browser path directly, regardless of the strategy setting. They work the same whether the strategy is `oauth`, `browser`, or `auto` — the strategy only affects `post` and `reply` commands.
-
-### User timeline
-
-```bash
-assistant x timeline <screenName> [--count N]
-```
-
-Returns `user` and `tweets` array.
-
-### Single tweet + replies
-
-```bash
-assistant x tweet <tweetIdOrUrl>
-```
-
-Returns the focal tweet and its reply thread.
-
-### Search
-
-```bash
-assistant x search "query" [--count N] [--product Top|Latest|People|Media]
-```
-
-### Home timeline
-
-```bash
-assistant x home [--count N]
-```
-
-### Bookmarks
-
-```bash
-assistant x bookmarks [--count N]
-```
-
-### Notifications
-
-```bash
-assistant x notifications [--count N]
-```
-
-Returns `notifications` array with `id`, `message`, `timestamp`, `url`.
-
-### Likes
-
-```bash
-assistant x likes <screenName> [--count N]
-```
-
-### Followers / Following
-
-```bash
-assistant x followers <screenName> [--count N]
-assistant x following <screenName> [--count N]
-```
-
-Returns `user` and `followers`/`following` array (userId, screenName, name).
-
-### Media
-
-```bash
-assistant x media <screenName> [--count N]
-```
-
-Returns tweets that contain media from the user's profile.
-
-## Workflows
-
-### Check Mentions
-
-When the user asks to check mentions, check X, or see what's happening:
-
-1. Fetch notifications: `assistant x notifications --count 20 --json`
-2. Fetch their recent tweets to see replies: `assistant x timeline <theirScreenName> --count 10 --json`
-3. Summarize what needs attention:
-   - Group by type: replies to their tweets, likes, new followers, mentions
-   - For anything that looks like it needs a reply, fetch the full thread with `assistant x tweet <tweetId>` to understand context
-   - Prioritize: direct questions > mentions > engagement notifications
-4. For items that need replies, draft a response and ask the user to approve before sending with `assistant x reply`
-
-Present the summary as a scannable list, not a wall of text. Lead with action items.
-
-### Research a Topic
-
-When the user wants to understand what people are saying about something:
-
-1. Search: `assistant x search "topic" --count 20 --json`
-2. For the most interesting tweets, fetch threads: `assistant x tweet <tweetId>`
-3. Summarize: key themes, notable voices, sentiment, and any emerging consensus
-4. If the user wants to engage, draft a post or reply that adds to the conversation
-
-### Engagement Check
-
-When the user wants to see how their posts are performing:
-
-1. Fetch their recent tweets: `assistant x timeline <screenName> --count 20 --json`
-2. For each tweet, note engagement signals from the text/metadata
-3. Fetch notifications to see who's interacting: `assistant x notifications --count 20 --json`
-4. Summarize: which posts got traction, who's engaging, any conversations worth continuing
-
-## Tips
-
-- Keep posts under 280 characters
-- All `screenName` arguments should be without the `@` prefix
-- All commands return JSON with an `ok` field
-- When drafting replies, match the tone of the conversation — casual threads get casual replies
-- Always show the user what you're about to post and get approval before sending
-- If a browser session is expired, refresh it with `assistant x refresh` before retrying, or suggest switching to OAuth for post/reply operations
-- If an operation fails, check `assistant x status --json` to diagnose the issue before retrying
-- The `post` and `reply` commands include a `pathUsed` field in their response so you can tell the user which connection method was used

package/src/config/bundled-skills/twitter/icon.svg

@@ -1,14 +0,0 @@
-<svg viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg">
-<rect width="16" height="16" fill="#ffffff"/>
-<rect x="2" y="2" width="12" height="12" fill="#000000"/>
-<rect x="4" y="5" width="2" height="1" fill="#ffffff"/>
-<rect x="5" y="4" width="1" height="3" fill="#ffffff"/>
-<rect x="6" y="5" width="2" height="1" fill="#ffffff"/>
-<rect x="10" y="5" width="2" height="1" fill="#ffffff"/>
-<rect x="11" y="4" width="1" height="3" fill="#ffffff"/>
-<rect x="12" y="5" width="2" height="1" fill="#ffffff"/>
-<rect x="4" y="9" width="1" height="2" fill="#ffffff"/>
-<rect x="5" y="8" width="6" height="1" fill="#ffffff"/>
-<rect x="11" y="9" width="1" height="2" fill="#ffffff"/>
-<rect x="5" y="11" width="6" height="1" fill="#ffffff"/>
-</svg>

package/src/config/bundled-skills/typescript-eval/SKILL.md

@@ -1,60 +0,0 @@
----
-name: typescript-eval
-description: Test TypeScript code snippets before persisting as skills
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🧪","vellum":{"display-name":"TypeScript Evaluation","user-invocable":false}}
----
-
-# TypeScript Evaluation
-
-When you need to test a TypeScript snippet before persisting it as a managed skill, use `bash` directly.
-
-## Workflow
-
-### 1. Write the snippet to a temp file
-
-```
-bash command="mkdir -p /tmp/vellum-eval && cat > /tmp/vellum-eval/snippet.ts << 'SNIPPET_EOF'
-<your code here>
-SNIPPET_EOF"
-```
-
-### 2. Run it with bun
-
-```
-bash command="bun run /tmp/vellum-eval/snippet.ts" timeout_seconds=10
-```
-
-### 3. For function-based testing
-
-If the snippet exports a `default` or `run` function, write a runner script:
-
-```
-bash command="cat > /tmp/vellum-eval/runner.ts << 'RUNNER_EOF'
-import * as mod from './snippet.ts';
-const fn = (mod as any).default ?? (mod as any).run;
-const input = {}; // mock input
-const result = await fn(input);
-console.log(JSON.stringify(result, null, 2));
-RUNNER_EOF"
-```
-
-Then run the runner:
-
-```
-bash command="bun run /tmp/vellum-eval/runner.ts" timeout_seconds=10
-```
-
-### 4. Clean up
-
-```
-bash command="rm -rf /tmp/vellum-eval/"
-```
-
-## Guidelines
-
-- **Iteration limit:** Max 3 attempts before asking the user for guidance.
-- **After successful test:** Persist with `scaffold_managed_skill` only after explicit user consent.
-- **Timeout:** Use `timeout_seconds=10` (or up to 20 for complex snippets).
-- **Error handling:** Read stdout/stderr from the bash output to diagnose failures.
-- **Never persist or delete skills without explicit user confirmation.**

package/src/config/bundled-skills/vercel-token-setup/SKILL.md

@@ -1,214 +0,0 @@
----
-name: vercel-token-setup
-description: Set up a Vercel API token for publishing apps using browser automation
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"▲","vellum":{"display-name":"Vercel Token Setup","includes":["browser"],"credential-setup-for":"vercel:api_token"}}
----
-
-You are helping your user set up a Vercel API token so they can publish apps to the web.
-
-## Client Check
-
-Determine whether the user has browser automation available (macOS desktop app) or is on a non-interactive channel (Telegram, SMS, etc.).
-
-- **macOS desktop app**: Follow the **Automated Setup** path below.
-- **Telegram or other channel** (no browser automation): Follow the **Manual Setup for Channels** path below.
-
----
-
-# Path A: Manual Setup for Channels (Telegram, SMS, etc.)
-
-When the user is on Telegram or any non-macOS client, walk them through a text-based setup. No browser automation is used — the user follows links and performs each action manually.
-
-### Channel Step 1: Confirm and Explain
-
-Tell the user:
-
-> **Setting up Vercel API Token**
->
-> Since I can't automate the browser from here, I'll walk you through each step with direct links. You'll need:
-> 1. A Vercel account (free tier works)
-> 2. About 2 minutes
->
-> Ready to start?
-
-If the user declines, acknowledge and stop.
-
-### Channel Step 2: Create the Token
-
-Tell the user:
-
-> **Step 1: Create an API token**
->
-> Open this link to go to your Vercel tokens page:
-> https://vercel.com/account/tokens
->
-> 1. Click **"Create"** (or **"Create Token"**)
-> 2. Set the token name to **"Vellum Assistant"**
-> 3. Select scope: **"Full Account"**
-> 4. Set expiration to the longest option available (or **"No Expiration"** if offered)
-> 5. Click **"Create Token"**
->
-> A token value will appear — **copy it now**, as it's only shown once.
-
-### Channel Step 3: Store the Token
-
-Tell the user:
-
-> **Step 2: Send me the token**
->
-> Please paste the token value into the secure prompt below.
-
-Present the secure prompt:
-
-```
-credential_store prompt:
-  service: "vercel"
-  field: "api_token"
-  label: "Vercel API Token"
-  description: "Paste the API token you just created on vercel.com"
-  placeholder: "Enter your Vercel API token"
-```
-
-Wait for the user to complete the prompt. Once received, store it:
-
-```
-credential_store store:
-  service: "vercel"
-  field: "api_token"
-  value: "<the token the user provided>"
-  allowedTools: ["publish_page", "unpublish_page"]
-  allowedDomains: ["api.vercel.com"]
-```
-
-### Channel Step 4: Done!
-
-> **Vercel is connected!** You can now publish apps to the web. Try clicking Publish on any app you've built.
-
----
-
-# Path B: Automated Setup (macOS Desktop App)
-
-You will automate Vercel token creation via the browser while the user watches. The user's only manual action is signing in to Vercel (if needed) and one copy-paste for the token value.
-
-## Browser Interaction Principles
-
-Vercel's UI may change over time. Do NOT memorize or depend on specific element IDs, CSS selectors, or DOM structures. Instead:
-
-1. **Screenshot first, act second.** Before every interaction, take a `browser_screenshot` to see the current visual state. Use `browser_snapshot` to find interactive elements.
-2. **Adapt to what you see.** If a button's label or position differs from what you expect, use the screenshot to find the correct element.
-3. **Verify after every action.** After clicking, typing, or navigating, take a new screenshot to confirm the action succeeded.
-4. **Never assume DOM structure.** Use the snapshot to identify what's on the page and interact accordingly.
-5. **When stuck, screenshot and describe.** If you cannot find an expected element after 2 attempts, take a screenshot, describe what you see to the user, and ask for guidance.
-
-## Anti-Loop Guardrails
-
-Each step has a **retry budget of 3 attempts**. An attempt is one try at the step's primary action (e.g., clicking a button, filling a form). If a step fails after 3 attempts:
-
-1. **Stop trying.** Do not continue retrying the same approach.
-2. **Fall back to manual.** Tell the user what you were trying to do and ask them to complete that step manually in the browser. Give them the direct URL and clear text instructions.
-3. **Resume automation** at the next step once the user confirms the manual step is done.
-
-If **two or more steps** require manual fallback, abandon the automated flow entirely and switch to giving the user the remaining steps as clear text instructions with links.
-
-## Things That Do Not Work — Do Not Attempt
-
-These actions are technically impossible in the browser automation environment:
-
-- **Downloading files.** `browser_click` on a Download button does not save files to disk.
-- **Reading the token value from a screenshot.** The token IS visible in the creation dialog, but you MUST NOT attempt to read it from a screenshot — it is too easy to misread characters, and the value must be exact. Always use the `credential_store prompt` approach to let the user copy-paste it accurately.
-- **Clipboard operations.** You cannot copy/paste via browser automation.
-
-## Step 1: Single Upfront Confirmation
-
-Tell the user:
-
-> **Setting up your Vercel API token so we can publish your app...**
->
-> Here's what will happen:
-> 1. **A browser opens** to your Vercel account settings
-> 2. **You sign in** (if not already signed in)
-> 3. **I create the token** — you just watch
-> 4. **One quick copy-paste** — I'll ask you to copy the token value into a secure prompt
->
-> Takes about a minute. Ready?
-
-If the user declines, acknowledge and stop. No further confirmations are needed after this point.
-
-## Step 2: Open Vercel and Sign In
-
-**Goal:** The user is signed in and the Vercel tokens page is loaded.
-
-Navigate to `https://vercel.com/account/tokens`.
-
-Take a screenshot and snapshot to check the page state:
-- **Sign-in page:** Tell the user: "Please sign in to your Vercel account in the browser." Then auto-detect sign-in completion by polling screenshots every 5-10 seconds. Check if the current URL has moved away from the login/sign-in page to the tokens page. Do NOT ask the user to "let me know when you're done" — detect it automatically. Once sign-in is detected, tell the user: "Signed in! Creating your API token now..."
-- **Already signed in:** Tell the user: "Already signed in — creating your API token now..." and continue immediately.
-
-**Verify:** URL contains `vercel.com/account/tokens` and no sign-in overlay is visible.
-
-## Step 3: Create Token
-
-**Goal:** A new API token named "Vellum Assistant" is created.
-
-Take a screenshot and snapshot. Find and click the button to create a new token (typically labeled "Create" or "Create Token").
-
-On the creation form:
-- Token name: **"Vellum Assistant"**
-- Scope: Select **"Full Account"** (or the broadest scope available)
-- Expiration: Select the longest option available, or **"No Expiration"** if offered
-- Click create/submit
-
-**Verify:** Take a screenshot. A dialog or section should now display the newly created token value.
-
-## Step 4: Capture Token via Secure Prompt
-
-**Goal:** The token value is securely captured and stored.
-
-### CRITICAL — Token Capture Protocol
-
-After token creation, Vercel shows the token value **once**. You MUST follow this exact sequence — **no improvisation**:
-
-1. Tell the user: "Your token has been created! Please copy the token value shown on screen and paste it into the secure prompt below."
-2. **IMMEDIATELY** present a `credential_store prompt` for the token. This is your ONLY next action.
-3. Wait for the user to paste the token.
-
-**Absolute prohibitions during this step:**
-- Do NOT try to read the token value from the screenshot. It must come from the user via secure prompt to ensure accuracy.
-- Do NOT navigate away from the page until the user has pasted the token.
-- Do NOT click any download or copy buttons.
-
-Present the secure prompt:
-
-```
-credential_store prompt:
-  service: "vercel"
-  field: "api_token"
-  label: "Vercel API Token"
-  description: "Copy the token value shown on the Vercel page and paste it here."
-  placeholder: "Enter your Vercel API token"
-```
-
-Wait for the user to complete the prompt. Once received, store it:
-
-```
-credential_store store:
-  service: "vercel"
-  field: "api_token"
-  value: "<the token the user provided>"
-  allowedTools: ["publish_page", "unpublish_page"]
-  allowedDomains: ["api.vercel.com"]
-```
-
-**Verify:** `credential_store list` shows `api_token` for `vercel`.
-
-## Step 5: Done!
-
-"**Vercel is connected!** Your API token is set up and ready to go. You can now publish apps to the web."
-
-## Error Handling
-
-- **Page load failures:** Retry navigation once. If it still fails, tell the user and ask them to check their internet connection.
-- **Element not found:** Take a fresh screenshot to re-assess. The Vercel UI may have changed. Describe what you see and try alternative approaches. If stuck after 2 attempts, ask the user for guidance.
-- **Token already exists with same name:** This is fine — Vercel allows multiple tokens with the same name. Proceed with creation.
-- **Any unexpected state:** Take a `browser_screenshot`, describe what you see, and ask the user for guidance.