@vellumai/assistant 0.4.43 → 0.4.45

package/src/config/bundled-skills/reminder/TOOLS.json

@@ -1,89 +0,0 @@
-{
-  "version": 1,
-  "tools": [
-    {
-      "name": "reminder_create",
-      "description": "Create a one-time time-based reminder. Reminders fire at a specific future time and either notify the user or execute a message through the assistant. Use this ONLY when the user wants a time-triggered notification (e.g. \"remind me at 3pm\", \"remind me in 2 hours\"). Do NOT use this for \"add to my tasks\" or \"add to my queue\" \u2014 use task_list_add for those requests.",
-      "category": "reminder",
-      "risk": "low",
-      "input_schema": {
-        "type": "object",
-        "properties": {
-          "fire_at": {
-            "type": "string",
-            "description": "ISO 8601 timestamp for when the reminder should fire"
-          },
-          "label": {
-            "type": "string",
-            "description": "Human-readable label"
-          },
-          "message": {
-            "type": "string",
-            "description": "Content shown in notification (notify) or sent to agent (execute)"
-          },
-          "mode": {
-            "type": "string",
-            "enum": ["notify", "execute"],
-            "description": "How the reminder fires. Defaults to notify."
-          },
-          "routing_intent": {
-            "type": "string",
-            "enum": ["single_channel", "multi_channel", "all_channels"],
-            "description": "How the reminder is routed at trigger time. single_channel delivers to one best channel, multi_channel delivers to a subset, all_channels (default) delivers everywhere."
-          },
-          "routing_hints": {
-            "type": "object",
-            "description": "Optional hints for the routing engine (e.g. preferred channels, exclusions)."
-          },
-          "reason": {
-            "type": "string",
-            "description": "Brief non-technical explanation of why this tool is being called"
-          }
-        },
-        "required": ["fire_at", "label", "message"]
-      },
-      "executor": "tools/reminder-create.ts",
-      "execution_target": "host"
-    },
-    {
-      "name": "reminder_list",
-      "description": "List all reminders and their current status.",
-      "category": "reminder",
-      "risk": "low",
-      "input_schema": {
-        "type": "object",
-        "properties": {
-          "reason": {
-            "type": "string",
-            "description": "Brief non-technical explanation of why this tool is being called"
-          }
-        },
-        "required": []
-      },
-      "executor": "tools/reminder-list.ts",
-      "execution_target": "host"
-    },
-    {
-      "name": "reminder_cancel",
-      "description": "Cancel a pending reminder by ID.",
-      "category": "reminder",
-      "risk": "low",
-      "input_schema": {
-        "type": "object",
-        "properties": {
-          "reminder_id": {
-            "type": "string",
-            "description": "Reminder ID to cancel"
-          },
-          "reason": {
-            "type": "string",
-            "description": "Brief non-technical explanation of why this tool is being called"
-          }
-        },
-        "required": ["reminder_id"]
-      },
-      "executor": "tools/reminder-cancel.ts",
-      "execution_target": "host"
-    }
-  ]
-}

package/src/config/bundled-skills/reminder/tools/reminder-list.ts

@@ -1,12 +0,0 @@
-import { executeReminderList } from "../../../../tools/reminder/reminder.js";
-import type {
-  ToolContext,
-  ToolExecutionResult,
-} from "../../../../tools/types.js";
-
-export async function run(
-  _input: Record<string, unknown>,
-  _context: ToolContext,
-): Promise<ToolExecutionResult> {
-  return executeReminderList();
-}

package/src/config/bundled-skills/restaurant-reservation/SKILL.md

@@ -1,141 +0,0 @@
----
-name: restaurant-reservation
-description: Book reservations on OpenTable or Resy with explicit confirmations
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🍽️","vellum":{"display-name":"Restaurant Reservation Booking","user-invocable":true,"disable-model-invocation":true,"includes":["browser"]}}
----
-
-Book restaurant reservations on OpenTable or Resy using browser automation.
-
-## 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, navigating a page). 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 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, inform the user the automated flow is unreliable and offer to provide the remaining steps as text instructions with links.
-
-## Booking Flow — Follow These Steps IN ORDER
-
-### Step 1: Collect Reservation Details
-
-Before doing anything, gather the following from the user:
-
-- **Party size** (required)
-- **Date** (required)
-- **Time or time window** (required)
-- **Location / neighborhood / city** (required)
-- **Restaurant name** (optional — if not provided, will search)
-- **Any preferences** (outdoor seating, dietary needs, etc.)
-
-Do not proceed until all required details have been provided.
-
-### Step 2: Choose Provider
-
-- If the user hasn't specified a provider, ask them to choose between **OpenTable** and **Resy**.
-- Do NOT attempt to browse provider sites to check restaurant availability before signing in — authentication is required first. If the user names a specific restaurant but isn't sure which provider has it, pick the more common one (OpenTable) and fall back to the other if it's not found after searching in Step 4.
-
-### Step 3: Navigate and Sign In FIRST
-
-This is the most important step. Reservation sites require authentication before booking.
-
-1. **Navigate directly to the sign-in page.**
-   - **For OpenTable**, navigate to: `https://www.opentable.com/sign-in`
-   - **For Resy**, navigate to: `https://resy.com/login`
-2. Take a `browser_snapshot`. If you see a sign-in form (email input), continue to sub-step 5 below (fill the email).
-3. **If the direct URL fails** (404, redirect, or any error): fall back to the homepage approach — navigate to the service's homepage and click the "Sign In" / "Log In" button.
-4. If already signed in (you see an account menu, the user's name, or other logged-in indicators), skip to the next step.
-5. Fill the email using `browser_fill_credential` (e.g. service: "opentable" or "resy", field: "email"). Target the element by its `element_id` — NEVER type into the browser URL bar.
-6. Click "Continue" / "Sign In" or equivalent submit button.
-7. The site will send a verification code via SMS/email. Use `ui_show` with `surface_type: "form"` and `await_action: true` to ask the user for the code. **Wait for the user to submit the form before proceeding** — do NOT use any previously collected code. Verification codes expire quickly; only the code from the most recent form submission is valid. Type the freshly submitted code into the verification input on the page.
-8. If the code is rejected, prompt the user again with a fresh `ui_show` form — never retry an old code.
-9. **For password-based login:** If the site presents a password field instead of a verification code, fill the password using `browser_fill_credential` (e.g. service: "opentable" or "resy", field: "password").
-
-### EVERY snapshot: Dismiss modals FIRST
-
-**Before every other action**, scan the snapshot for **non-functional** modal overlays and dismiss them. Modals block all interactions — clicking behind a modal silently fails.
-- **DO NOT dismiss sign-in/login modals** — if you see an email input or sign-in form inside a modal, that IS the sign-in flow. Fill it in, don't close it.
-- Dismiss only blocker modals: cookie banners, regulatory notices, promotional popups.
-- Look for: "Got It", "Accept", "Close", "OK", "Dismiss" buttons on non-login modals.
-- Take a fresh snapshot after dismissing to confirm the modal is gone.
-
-### Step 4: Search for Availability
-
-1. **For OpenTable**, navigate directly to:
-   `https://www.opentable.com/s?covers=<party_size>&dateTime=<YYYY-MM-DDTHH:MM>&term=<restaurant_or_location>`
-   Construct the URL from the details collected in Step 1. URL-encode the `term` parameter.
-2. **For Resy**, navigate to `https://resy.com/cities/<city>` and use the search/filter UI to find available reservations matching the collected details.
-3. If a specific restaurant was named, navigate directly to its page if possible (e.g. `https://www.opentable.com/r/<restaurant-slug>` or `https://resy.com/cities/<city>/venues/<restaurant-slug>`). **After landing on the restaurant page, reapply the user's date, time, and party size filters** — direct restaurant URLs often show default availability that may not match the user's request. Use the on-page date picker, time selector, and party size controls to set the correct values before reviewing slots.
-4. Take a `browser_snapshot` and review the results.
-5. **If the named restaurant is not found on this provider**, tell the user and offer to try the other provider (OpenTable <-> Resy). If they agree, go back to Step 3 to sign in to the other provider.
-
-### Step 5: Present Available Slots
-
-1. Extract available time slots from the page.
-2. Present them to the user in a clear, organized format.
-3. If **NO slots** match the requested time:
-   - Offer nearby times on the same date.
-   - Offer the same time on adjacent dates.
-   - Suggest trying the other provider (OpenTable <-> Resy).
-4. Let the user choose a slot.
-5. **Click the chosen slot on the page** to select it. Take a fresh `browser_snapshot` to confirm the slot is selected and the booking/confirmation form is now visible. Do not proceed to confirmation steps until the slot is actively selected in the site UI.
-
-### Step 6: First Confirmation — Reservation Details + Policies
-
-Before proceeding to book, show the user a summary:
-- Restaurant name
-- Date and time
-- Party size
-- Any special notes
-
-**CRITICAL: Surface cancellation policies and fees prominently.** Look for and extract:
-- Cancellation deadlines (e.g., "Cancel by 4 hours before")
-- No-show fees (e.g., "$25 per person no-show fee")
-- Deposit requirements
-- Credit card hold amounts
-
-**If the restaurant charges a cancellation or no-show fee, call it out explicitly in a separate line** — do not bury it in other details. Example: "This restaurant charges a $25/person no-show fee."
-
-Ask the user to confirm they want to proceed.
-
-### Step 7: Final Confirmation — Pre-Submit Approval
-
-Immediately before clicking the final "Complete Reservation" / "Confirm" button, ask one more time:
-- "Ready to submit this reservation? This action cannot be undone."
-
-Only proceed after explicit user approval.
-
-### Step 8: Submit and Confirm
-
-1. Click the final reservation submit button.
-2. Take a `browser_snapshot` to confirm success.
-3. Extract and present to the user:
-   - Confirmation number / reference ID (if visible)
-   - Confirmation page link
-   - Final reservation details as shown on the confirmation page
-4. If the submission fails, take a fresh `browser_snapshot` and report the error.
-
-## Critical Rules
-
-- **ALWAYS sign in first.** Do not attempt to search or browse availability before signing in.
-- **NEVER tell the user to sign in themselves.** You handle ALL authentication using `browser_fill_credential` and `ui_show` for verification codes.
-- **NEVER give up.** If an interaction fails, take a fresh `browser_snapshot` and retry with updated element IDs — within the 3-attempt budget per step.
-- **Target elements by `element_id`** from `browser_snapshot`. Never fabricate CSS selectors.
-- **Use `browser_select_option` for native `<select>` dropdowns** (e.g., party size selectors). For non-native dropdowns, ARIA listboxes, and date/time pickers, use `ArrowDown`/`ArrowUp` + `Enter` via `browser_press_key`.
-- **Use `browser_scroll`** to reveal off-screen time slots or search results before interacting with them.
-- **Handle CAPTCHAs:** If a Cloudflare/CAPTCHA challenge appears, wait a few seconds — it often auto-resolves. If it persists, the system will hand off to the user automatically.
-- **Fresh snapshots after every action** that changes the page. Element IDs go stale after navigation or DOM updates.
-- **Conserve context.** Browser flows are token-heavy. Avoid unnecessary snapshots — only take one when the page changes. Combine multiple actions efficiently. Do not narrate every step in detail.
-- **ALWAYS surface cancellation and no-show fees.** Before confirming any reservation, check for cancellation policies, no-show fees, deposits, and credit card holds. If the restaurant charges any fee, call it out explicitly — do not bury it in other details. The user must acknowledge fees before you proceed.
-- **Two confirmations required.** Never submit a reservation without both the policy confirmation (Step 6) and the final pre-submit confirmation (Step 7).
-
-## Error Handling
-
-- **Search returns no results:** Try alternate search terms, broaden the location, or check spelling. If still nothing, suggest the other provider (OpenTable <-> Resy).
-- **Expired OTP:** Never retry an old verification code. Always prompt the user for a fresh code via `ui_show` with `await_action: true`.
-- **Login fails repeatedly:** After 3 failed attempts, inform the user and ask if they want to try the other provider or handle login manually.
-- **Reservation submit fails:** Take a fresh `browser_snapshot`, read the error message, and report it to the user. Common causes: credit card required, party size changed, slot no longer available. Suggest rebooking if the slot was taken.
-- **Page unresponsive or stuck:** Wait up to 10 seconds, then try refreshing (`browser_navigate` to the current URL). If still stuck, report to the user.
-- **Provider-specific errors:** If one provider consistently errors, suggest switching to the other.

package/src/config/bundled-skills/screen-recording/SKILL.md

@@ -1,148 +0,0 @@
----
-name: screen-recording
-description: Record the user's screen as a video file
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🎬","vellum":{"display-name":"Screen Recording","os":["darwin"]}}
----
-
-Capture screen recordings as video files attached to the conversation.
-
-## Activation
-
-This skill activates when the user asks to record their screen. Common phrases:
-
-**Start recording:**
-
-- "record my screen"
-- "start recording"
-- "begin recording"
-- "capture my screen"
-- "capture my display"
-- "make a recording"
-- "Nova, record my screen" (where Nova is the assistant's identity name)
-- "hey Nova, start recording"
-
-**Stop recording:**
-
-- "stop recording"
-- "end recording"
-- "finish recording"
-- "halt recording"
-
-**Restart recording:**
-
-- "restart recording"
-- "redo the recording"
-- "stop recording and start a new one"
-- "stop recording and start a new recording"
-- "stop and restart the recording"
-
-**Pause recording:**
-
-- "pause recording"
-- "pause the recording"
-
-**Resume recording:**
-
-- "resume recording"
-- "unpause the recording"
-
-## Intent Classification
-
-Recording prompts are classified by `resolveRecordingIntent` into one of 11 intent kinds:
-
-### Pure commands (handled by the standalone recording route)
-
-- **`start_only`** — Pure start request with no additional task (e.g., "record my screen").
-- **`stop_only`** — Pure stop request (e.g., "stop recording").
-- **`restart_only`** — Pure restart request (e.g., "restart recording", "stop recording and start a new one").
-- **`pause_only`** — Pure pause request (e.g., "pause the recording").
-- **`resume_only`** — Pure resume request (e.g., "resume the recording").
-
-### Recording + additional task (recording action is deferred and executed alongside the task)
-
-- **`start_with_remainder`** — Start recording embedded in a broader task. The recording clause is stripped, and the remainder is processed as a separate task. Example: "open Safari and record my screen" produces remainder "open Safari".
-- **`stop_with_remainder`** — Stop recording embedded in a broader task. Example: "close the browser and stop recording" produces remainder "close the browser".
-- **`restart_with_remainder`** — Restart recording embedded in a broader task. Example: "restart recording and open Safari" produces remainder "open Safari".
-
-### Both start and stop detected
-
-- **`start_and_stop_only`** — Both start and stop patterns present with no additional task (e.g., "stop recording and record my screen").
-- **`start_and_stop_with_remainder`** — Both start and stop patterns present alongside additional task text.
-
-### No recording intent
-
-- **`none`** — No recording intent detected. Normal routing.
-
-Dynamic name prefixes (from IDENTITY.md) are stripped during classification, so "Nova, record my screen" classifies the same as "record my screen".
-
-## Routing
-
-Recording intent resolution follows a precedence chain:
-
-### 1. `commandIntent` (structured IPC) — highest priority
-
-The macOS client can send structured intents with `domain: 'screen_recording'` and `action: 'start' | 'stop' | 'restart' | 'pause' | 'resume'`. These bypass text parsing entirely. The assistant checks for `commandIntent` before any text analysis.
-
-### 2. Deterministic text resolver (`resolveRecordingIntent`)
-
-A regex-based pipeline that classifies the user's text. The pipeline:
-
-1. Strips dynamic assistant names (leading vocative like "Nova, ...")
-2. Strips leading polite wrappers ("please", "can you", etc.)
-3. Applies the interrogative guard — WH-questions return `none`
-4. Checks restart compound patterns (before independent start/stop, so "stop recording and start a new one" is recognized as restart)
-5. Checks pause/resume patterns
-6. Checks start and stop patterns independently
-7. Determines if the intent is pure or has a remainder by stripping recording clauses and checking for substantive remaining content
-
-### 3. Normal processing
-
-If no recording intent is detected (kind is `none`), the message flows to the classifier and computer-use session as usual.
-
-## Interrogative Guard
-
-Questions about recording are NOT treated as commands. The resolver filters out WH-questions to prevent side effects from informational queries.
-
-**Filtered (no recording action triggered):**
-
-- "how do I stop recording?"
-- "what does screen recording do?"
-- "why is the recording paused?"
-- "when should I stop recording?"
-
-**Preserved as commands (recording action IS triggered):**
-
-- "can you stop recording?" — polite imperative
-- "could you record my screen?" — polite imperative
-- "please stop recording" — direct command with filler
-
-The guard checks for WH-question starters (how, what, why, when, where, who, which) at the beginning of the text, after stripping dynamic names and polite prefixes.
-
-## Mixed-Intent Examples
-
-When a recording intent is combined with another task, the recording clause is stripped from the text, and both parts are handled:
-
-- **"open Safari and record my screen"** — `start_with_remainder` with remainder "open Safari". Recording starts alongside the Safari task.
-- **"stop recording and start a new one and open Safari"** — `restart_with_remainder` with remainder "open Safari". Restart executes and the remainder is processed separately.
-- **"close the browser and stop recording"** — `stop_with_remainder` with remainder "close the browser". Stop executes and the remainder is processed.
-
-The remainder preserves the user's original phrasing (stripping is applied to the original text, not the normalized form).
-
-## Behavior Rules
-
-1. **Do not invoke computer use** for recording-only requests. The assistant handles these directly.
-2. **One recording at a time.** If a recording is already active, starting another returns an "already recording" message.
-3. **Conversation-linked.** Each recording is linked to the conversation that started it for attachment purposes. However, since only one recording can be active at a time, stop commands from any conversation will stop the active recording regardless of which conversation started it.
-4. **Permission required.** Screen recording requires macOS Screen Recording permission. If denied, the user sees actionable guidance to enable it in System Settings.
-5. **Mixed-intent prompts** (recording + other task) are NOT intercepted by the standalone route — the recording action is deferred and executed alongside the task.
-6. **Restart always reopens the source picker** and requires source reselection.
-7. **Restart cancel** (user closes the source picker) leaves state idle — no false "recording started" message.
-8. **Pause/resume toggle the recording** without stopping it. The HUD shows paused state.
-
-## What This Skill Does NOT Do
-
-- This skill does not contain recorder logic — the `RecordingManager` and `ScreenRecorder` in the macOS app handle the actual recording.
-- This skill does not provide shell commands or scripts for recording.
-- This skill does not fall back to computer use for recording tasks.
-- This skill does not handle informational questions about recording — those flow through to normal AI response.

package/src/config/bundled-skills/self-upgrade/SKILL.md

@@ -1,69 +0,0 @@
----
-name: self-upgrade
-description: Upgrade vellum to the latest version, restart the assistant, and restart the gateway
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"⬆️","vellum":{"display-name":"Self Upgrade","user-invocable":true}}
----
-
-You are performing a self-upgrade of the Vellum assistant. Follow these steps **in order**. Use the `bash` tool to run each command. Confirm each step succeeds before moving to the next.
-
-## Step 1: Record the current version
-
-```bash
-vellum --version
-```
-
-Save this value to report later.
-
-## Step 2: Install the latest vellum
-
-```bash
-bun install -g vellum@latest
-```
-
-After updating, verify the new version:
-
-```bash
-vellum --version
-```
-
-## Step 3: Restart the gateway
-
-If a gateway process is running, restart it so it picks up any protocol or dependency changes from the new version:
-
-```bash
-pgrep -f 'vellum-gateway|gateway/src/index.ts' || echo "No gateway process found"
-```
-
-If a gateway PID is found, send it SIGTERM so it drains gracefully:
-
-```bash
-pkill -TERM -f 'vellum-gateway|gateway/src/index.ts'
-```
-
-Then start the gateway again using whatever method the user's deployment uses (e.g. `bun run gateway/src/index.ts`, a systemd service, or a container orchestrator). If you are unsure how the gateway is deployed, ask the user.
-
-## Step 4: Restart the assistant
-
-Use `vellum sleep` to stop the running assistant and gateway, then `vellum wake` to start them again from the updated binary:
-
-```bash
-vellum sleep && vellum wake
-```
-
-Verify it is running:
-
-```bash
-vellum ps
-```
-
-**Important:** This is the last step because the current assistant process is the one executing this conversation. After the restart, the new assistant takes over and this session ends gracefully.
-
-## After Upgrade
-
-Report back to the user with:
-
-- The previous and new vellum version
-- Assistant status (running, PID)
-- Gateway status (restarted or not found)
-- Any errors encountered during the process

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

@@ -1,78 +0,0 @@
----
-name: skills-catalog
-description: Discover bundled skills and search/install community skills from Clawhub
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🧩","vellum":{"display-name":"Skills Catalog","user-invocable":true}}
----
-
-You can help the user discover what skills are available and find community skills to extend the assistant's capabilities.
-
-## Bundled skills (first-party)
-
-First-party skills are **bundled** with the assistant — they are compiled in and always available. They do not need to be installed or downloaded. To activate a bundled skill, use the `skill_load` tool:
-
-```
-skill_load skill=<skill-id>
-```
-
-The skill catalog shown in the system prompt lists all bundled skills with their IDs. When a user asks about capabilities, refer to this list to find relevant bundled skills and load them as needed.
-
-## Community skills (Clawhub)
-
-Community skills are published on Clawhub and can be searched, inspected, and installed on demand using the `clawhub` CLI via bash.
-
-### Searching for community skills
-
-```bash
-npx clawhub search "<query>" --limit 10
-```
-
-Returns matching skills with their slug, version, and name. Use this when the user asks for a capability not covered by bundled skills.
-
-To browse trending/popular skills without a specific query:
-
-```bash
-npx clawhub explore --json --limit 10
-```
-
-### Inspecting a community skill
-
-Before installing, inspect a skill to review its metadata, author, stats, and SKILL.md content:
-
-```bash
-npx clawhub inspect <slug> --json --files --file SKILL.md
-```
-
-Present the results to the user so they can decide whether to install.
-
-### Installing a community skill
-
-```bash
-npx clawhub install <slug> --force --workdir ~/.vellum/workspace
-```
-
-Once installed, the skill appears in `~/.vellum/workspace/skills/<slug>/` and can be loaded with `skill_load` like any other skill.
-
-## Typical flow
-
-1. **User asks about capabilities** — "Can you order food?" or "What can you do?"
-   - Check the bundled skills list in the system prompt
-   - Present relevant skills to the user
-   - Load any that match with `skill_load`
-
-2. **User wants a capability not covered by bundled skills** — "Can you do X?"
-   - Search with `npx clawhub search "<query>"`
-   - Optionally inspect promising results with `npx clawhub inspect <slug> --json`
-   - Present matching results with descriptions and install counts
-   - Install the chosen skill with `npx clawhub install <slug> --force --workdir ~/.vellum/workspace`
-   - Load it with `skill_load`
-
-3. **Skill has dependencies** — if `includes` lists other skill IDs, load those first with `skill_load`
-
-## Notes
-
-- Bundled skills are always available and do not need installation
-- Community skills are installed to `~/.vellum/workspace/skills/<slug>/`
-- After installing a community skill, it is auto-enabled and immediately loadable
-- Skills can be enabled or disabled via feature flags without uninstalling them
-- Run `npx clawhub --help` to discover additional CLI options