@vellumai/assistant 0.4.42 → 0.4.44

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

@@ -1,71 +1,71 @@
 ---
-name: "X"
-description: "Read and post on X (formerly Twitter) via OAuth or browser session"
-user-invocable: true
-metadata: { "vellum": { "emoji": "𝕏" } }
+name: twitter
+description: Read and post on X (formerly Twitter) via OAuth or managed mode
+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 two supported ways to connect to X. Both are fully functional; choose whichever fits the user's situation.
+There are two supported ways to connect to X. Choose whichever fits the user's situation.
 
-### OAuth (recommended with X developer credentials)
+### Managed mode (platform-hosted credentials)
 
-OAuth uses the official X API v2. It is the most reliable connection method and does not depend on browser sessions.
+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 is needed.
 
-- 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`
+- Supports: **post**, **reply**, and **read** operations (routed through the platform proxy)
+- 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.
 
-### Browser session (no developer credentials needed)
+**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.
 
-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.
+**Architecture notes for managed mode:**
 
-- 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`
+- **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 authentication.** The macOS Settings UI calls the platform's Twitter OAuth endpoints using the user's WorkOS-issued token. 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 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.
 
-### Auto mode (default)
+### OAuth (recommended with X developer credentials)
 
-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.
+OAuth uses the official X API v2. It is the most reliable local connection method.
 
-- Set auto mode: `assistant config set twitter.operationStrategy auto`
+- Supports: **post** and **reply**
+- 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.
 
 ## First-Use Decision Flow
 
-When the user triggers a Twitter operation and no strategy has been configured yet, follow these steps:
+When the user triggers a Twitter operation and no connection 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
+   # Check integration mode
+   assistant config get twitter.integrationMode
    ```
 
-   If the strategy is not set, the user has not yet chosen a strategy and should be guided through setup.
+2. **Determine the best path:**
+   - If managed mode prerequisites are met (integration mode is `managed`, assistant is registered with the platform, API key is present, and the owner has connected their Twitter account), use managed mode.
+   - Otherwise, guide the user through OAuth 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:**
+3. **Execute setup for the chosen path:**
+   - If managed: Confirm prerequisites are satisfied. Managed mode requires no local setup beyond platform registration.
    - 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.
+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, 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"`.
@@ -74,97 +74,72 @@ When the user chooses OAuth, collect their X developer credentials conversationa
    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.
+   Trigger the Twitter auth start flow. The connect orchestrator resolves the Twitter provider profile, computes scopes via policy, opens the X authorization page, 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.
+   - `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.
+   - `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`.
-
-4. **Offer concrete steps to switch:**
+3. **Suggest recovery steps:**
+   - If OAuth failed or is not configured: suggest reconnecting OAuth credentials or checking that the X developer app credentials are correct.
+   - 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.).
 
-   ```bash
-   # Switch to the other strategy
-   assistant config set twitter.operationStrategy <oauth|browser|auto>
-
-   # If switching to browser, refresh the session
-   assistant x refresh
-   ```
+## Posting
 
-## Strategy Management Commands
+Before posting, check the integration mode:
 
 ```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
+MODE=$(assistant config get twitter.integrationMode)
 ```
 
-## Posting
-
-Before posting, fetch the current strategy and OAuth token:
+Then post based on the mode:
 
 ```bash
-# 1. Get the configured strategy
-STRATEGY=$(assistant config get twitter.operationStrategy)
-# If not set, default to "auto"
+# Managed mode -- route through platform proxy (no local token needed):
+assistant x post "The post text here" --managed
 
-# 2. If strategy is "oauth" or "auto", get a valid OAuth token
+# With OAuth token:
 TOKEN=$(assistant oauth token twitter)
+assistant x post "The post text here" --oauth-token "$TOKEN"
 ```
 
-Then post with the fetched values:
+When `twitter.integrationMode` is `managed`, always use `--managed`. The platform proxy handles authentication.
 
-```bash
-# With OAuth token (strategy is oauth or auto):
-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
-```
-
-Returns JSON with `ok`, `tweetId`, `text`, `url`, and `pathUsed` fields. Share the URL with the user so they can verify the post.
+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 — fetch strategy and token first, then:
+Same setup as posting -- check integration mode first, then:
 
 ```bash
-assistant x reply <tweetUrl> "The reply text here" --strategy "$STRATEGY" --oauth-token "$TOKEN"
+# Managed mode:
+assistant x reply <tweetUrl> "The reply text here" --managed
+
+# Local OAuth:
+TOKEN=$(assistant oauth token twitter)
+assistant x reply <tweetUrl> "The reply text here" --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.
+Read operations are available in managed mode. They route through the platform proxy.
 
 ### User timeline
 
@@ -185,65 +160,21 @@ Returns the focal tweet and its reply thread.
 ### Search
 
 ```bash
-assistant x search "query" [--count N] [--product Top|Latest|People|Media]
+assistant x search "query" [--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
+1. Fetch their recent tweets to see replies: `assistant x timeline <theirScreenName> --count 10 --json`
+2. Summarize what needs attention:
+   - Group by type: replies to their tweets, 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`
+   - Prioritize: direct questions > mentions > engagement
+3. 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.
 
@@ -262,16 +193,14 @@ 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
+3. 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
+- 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/typescript-eval/SKILL.md

@@ -1,8 +1,8 @@
 ---
-name: "TypeScript Evaluation"
-description: "Test TypeScript code snippets before persisting as skills"
-user-invocable: false
-metadata: {"vellum": {"emoji": "🧪"}}
+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

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

@@ -1,9 +1,8 @@
 ---
-name: "Vercel Token Setup"
-description: "Set up a Vercel API token for publishing apps using browser automation"
-includes: ["browser"]
-credential-setup-for: "vercel:api_token"
-metadata: {"vellum": {"emoji": "▲"}}
+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.

package/src/config/bundled-skills/voice-setup/SKILL.md

@@ -1,8 +1,8 @@
 ---
-name: "Voice Setup"
-description: "Complete voice configuration in chat — PTT key, wake word, microphone permissions, ElevenLabs TTS, and troubleshooting"
-user-invocable: true
-metadata: {"vellum": {"emoji": "🎙️", "os": ["darwin"]}}
+name: voice-setup
+description: Complete voice configuration in chat — PTT key, wake word, microphone permissions, ElevenLabs TTS, and troubleshooting
+compatibility: "Designed for Vellum personal assistants"
+metadata: {"emoji":"🎙️","vellum":{"display-name":"Voice Setup","user-invocable":true,"includes":["elevenlabs-voice"],"os":["darwin"]}}
 ---
 
 You are helping the user set up and troubleshoot voice features (push-to-talk, wake word, text-to-speech) entirely within this conversation. Do NOT direct the user to the Settings page for initial setup — handle everything in-chat using the tools below.
@@ -23,6 +23,7 @@ Walk the user through each section in order. Skip sections they don't need. Ask
 Check `<channel_capabilities>` for `microphone_permission_granted`.
 
 **If `false` or missing:**
+
 1. Explain that macOS requires microphone permission for voice features.
 2. Use `open_system_settings` with `pane: "microphone"` to open the right System Settings pane.
 3. Tell the user: "I've opened System Settings to the Microphone section. Please toggle **Vellum Assistant** on, then come back here."
@@ -33,14 +34,16 @@ Check `<channel_capabilities>` for `microphone_permission_granted`.
 ### 2. Push-to-Talk Activation Key
 
 Present common PTT key options:
-- **Right Option (⌥)** — Default, good general choice
+
+- **Right Option** — Default, good general choice
 - **Fn** — Dedicated key on most Mac keyboards
-- **Right Command (⌘)** — Easy to reach
-- **Right Control (⌃)** — Familiar from gaming
+- **Right Command** — Easy to reach
+- **Right Control** — Familiar from gaming
 
 Ask which key they prefer, then use `voice_config_update` with `setting: "activation_key"` and the chosen value.
 
 **Common issues to mention:**
+
 - If they pick a key that conflicts with their emoji picker (Fn or Globe on newer Macs), warn them and suggest an alternative.
 - If they use a terminal app heavily, warn that some keys may be captured by the terminal.
 
@@ -49,6 +52,7 @@ Ask which key they prefer, then use `voice_config_update` with `setting: "activa
 Ask if they want to enable wake word detection (hands-free activation by saying a keyword).
 
 **If yes:**
+
 1. Use `voice_config_update` with `setting: "wake_word_enabled"`, `value: true`.
 2. Ask what wake word they want. Common choices: "Hey Vellum", "Computer", "Jarvis", their assistant's name.
 3. Use `voice_config_update` with `setting: "wake_word_keyword"` and their chosen word.
@@ -61,49 +65,14 @@ Ask if they want to enable wake word detection (hands-free activation by saying
 
 Ask if they want high-quality text-to-speech voices via ElevenLabs (optional — standard TTS works without it).
 
-**If yes:**
-1. Tell them they need an ElevenLabs API key. They can get one at https://elevenlabs.io (free tier available).
-2. Use `credential_store` with `action: "prompt"`, `service: "elevenlabs"`, `field: "api_key"` to show a secure input dialog.
-3. After the key is stored, confirm success.
-
-#### Choose an ElevenLabs voice
-
-After storing the API key, let the user pick their preferred voice. The shared config key `elevenlabs.voiceId` controls the voice for **both** in-app TTS and phone calls (defaulting to Rachel).
-
-Check the current voice:
-
-```bash
-assistant integrations voice config --json
-```
-
-Use `voiceId` from the response as the current selection (and `usesDefaultVoice` to know if Rachel is still in use by default). Ask the user if they want to change their TTS voice. If yes, use `voice_config_update` with `setting: "tts_voice_id"` and the chosen voice ID. This writes to both the config file (`elevenlabs.voiceId`) and pushes to the macOS app via IPC in one call.
-
-Common choices from the curated ElevenLabs list:
-- **Rachel** (`21m00Tcm4TlvDq8ikWAM`) — Calm, warm, conversational (default)
-- **Sarah** (`EXAVITQu4vr4xnSDxMaL`) — Soft, young, approachable
-- **Charlotte** (`XB0fDUnXU5powFXDhCwa`) — Warm, Swedish-accented
-- **Josh** (`TxGEqnHWrfWFTfGW9XjX`) — Deep, young, clear
-- **Adam** (`pNInz6obpgDQGcFmaJgB`) — Deep, middle-aged, professional
+If yes, the included **ElevenLabs Voice** skill (automatically appended below via `includes`) provides the full setup flow: curated voice list, API key collection, advanced voice selection, and tuning parameters. Follow the instructions there.
 
-If the user wants to browse more voices, they can search at https://elevenlabs.io/voice-library or use the ElevenLabs API with their key.
-
-#### Sync with phone calls
-
-After setting the voice, check whether phone calls are configured:
-
-```bash
-assistant integrations voice config --json
-```
-
-**If phone calls are enabled** (`callsEnabled` is `true`):
-- Tell the user their phone calls will automatically use the same voice they just chose, since both in-app TTS and phone calls read from `elevenlabs.voiceId`.
-
-**If phone calls are not yet configured** (`callsEnabled` is `false`):
-- Tell the user: "When you set up phone calls later, they'll automatically use the same voice for a consistent experience."
+Note: The shared config key `elevenlabs.voiceId` controls the voice for both in-app TTS and phone calls. If the user sets up phone calls later, they will automatically use the same voice for a consistent experience.
 
 ### 5. Verification
 
 After setup is complete:
+
 1. Summarize what was configured.
 2. Suggest they test by pressing their PTT key (or saying their wake word) and speaking.
 3. Offer to open the Voice settings tab if they want to review: use `navigate_settings_tab` with `tab: "Voice"`.
@@ -113,6 +82,7 @@ After setup is complete:
 When the user reports a problem, follow the appropriate decision tree:
 
 ### "PTT isn't working" / "Can't record"
+
 1. **Microphone permission** — Check `microphone_permission_granted` in capabilities. If false, guide through granting it.
 2. **Key check** — Ask what key they're using. Confirm it matches their configured PTT key.
 3. **Emoji picker conflict** — On newer Macs, Fn/Globe opens the emoji picker. If they're using Fn, suggest switching to Right Option or Right Command.
@@ -120,12 +90,14 @@ When the user reports a problem, follow the appropriate decision tree:
 5. **App focus** — PTT may not work when Vellum is not the frontmost app or if another app has captured the key.
 
 ### "Recording but no text" / "Transcription not working"
+
 1. **Speech Recognition permission** — Must be granted for transcription.
 2. **Microphone input** — Ask if they see the recording indicator. If yes, the mic works but transcription is failing.
 3. **Locale/language** — Speech recognition works best with the system language. Ask if they're speaking in a different language.
 4. **Background noise** — Excessive noise can prevent transcription. Suggest a quieter environment or a closer microphone.
 
 ### "Wake word not detecting"
+
 1. **Enabled check** — Confirm wake word is enabled in their settings.
 2. **Keyword** — Confirm what keyword they're using. Shorter or common words may have lower accuracy.
 3. **Ambient noise** — Wake word detection is sensitive to background noise.
@@ -133,6 +105,7 @@ When the user reports a problem, follow the appropriate decision tree:
 5. **Timeout** — If wake word activates but cuts off too quickly, increase the timeout.
 
 ### "Changed a setting but it didn't work"
+
 1. **IPC broadcast** — The setting should take effect immediately. If it didn't, suggest restarting the assistant.
 2. **Verify** — Open the Voice settings tab with `navigate_settings_tab` to confirm the setting was persisted.
 
@@ -145,6 +118,7 @@ log stream --predicate 'subsystem == "com.vellum.assistant"' --level debug
 ```
 
 Key log categories:
+
 - `voice` — PTT activation, recording state
 - `wake-word` — Wake word detection events
 - `speech` — Speech recognition results

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

@@ -1,7 +1,8 @@
 ---
-name: "Watcher"
-description: "Polling watcher system for monitoring external sources"
-metadata: {"vellum": {"emoji": "👀"}}
+name: watcher
+description: Polling watcher system for monitoring external sources
+compatibility: "Designed for Vellum personal assistants"
+metadata: {"emoji":"👀","vellum":{"display-name":"Watcher"}}
 ---
 
 Create and manage watchers that poll external services for events and process them with an action prompt.

package/src/config/env-registry.ts

@@ -43,15 +43,6 @@ export function getBaseDataDir(): string | undefined {
   return str("BASE_DATA_DIR");
 }
 
-/**
- * VELLUM_DAEMON_SOCKET — string, default: ~/.vellum/vellum.sock
- * Overrides the Unix domain socket path for daemon IPC.
- * Supports ~ expansion.
- */
-export function getDaemonSocket(): string | undefined {
-  return str("VELLUM_DAEMON_SOCKET");
-}
-
 /**
  * VELLUM_DAEMON_TCP_PORT — number, default: 8765
  * TCP port for the daemon's TCP listener (used by iOS clients).
@@ -141,7 +132,6 @@ export function getIsContainerized(): boolean {
  * to warn about typos or unrecognized variables.
  */
 const KNOWN_VELLUM_VARS = new Set([
-  "VELLUM_DAEMON_SOCKET",
   "VELLUM_DAEMON_TCP_PORT",
   "VELLUM_DAEMON_TCP_ENABLED",
   "VELLUM_DAEMON_TCP_HOST",
@@ -159,6 +149,7 @@ const KNOWN_VELLUM_VARS = new Set([
   "VELLUM_CLAUDE_CODE_DEPTH",
   "VELLUM_ASSISTANT_PLATFORM_URL",
   "VELLUM_UNSAFE_AUTH_BYPASS",
+  "VELLUM_DATA_DIR",
 ]);
 
 /**

package/src/config/feature-flag-registry.json

@@ -1,14 +1,6 @@
 {
   "version": 1,
   "flags": [
-    {
-      "id": "sms",
-      "scope": "assistant",
-      "key": "feature_flags.sms.enabled",
-      "label": "SMS",
-      "description": "Show SMS setup in Settings > Connect and enable the SMS setup skill",
-      "defaultEnabled": false
-    },
     {
       "id": "hatch-new-assistant",
       "scope": "assistant",
@@ -81,14 +73,6 @@
       "description": "Enable user-hosted onboarding flow",
       "defaultEnabled": false
     },
-    {
-      "id": "local-http-enabled",
-      "scope": "macos",
-      "key": "local_http_enabled",
-      "label": "Local HTTP Enabled",
-      "description": "Enable local HTTP transport mode in macOS app",
-      "defaultEnabled": false
-    },
     {
       "id": "command-palette",
       "scope": "assistant",
@@ -120,6 +104,14 @@
       "label": "App Builder Multi-file",
       "description": "Enable multi-file TSX app creation with esbuild compilation instead of single-HTML apps",
       "defaultEnabled": false
+    },
+    {
+      "id": "sentry-testing",
+      "scope": "macos",
+      "key": "sentry_testing_enabled",
+      "label": "Sentry Testing",
+      "description": "Show the Sentry Testing tab in Settings for triggering test crash reports and error events",
+      "defaultEnabled": false
     }
   ]
 }