@vellumai/assistant 0.4.44 → 0.4.45

package/src/config/bundled-skills/api-mapping/SKILL.md

@@ -1,78 +0,0 @@
----
-name: api-mapping
-description: Record and analyze API surfaces of web services
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🗺️","vellum":{"display-name":"API Mapping","user-invocable":true}}
----
-
-You can record and analyze the API surface of any web service using the `map` CLI.
-
-## CLI Setup
-
-**IMPORTANT: Always use `host_bash` (not `bash`) for all `map` commands.** The API mapping CLI needs host access for Chrome CDP, network recording, and browser automation — none of which are available inside the sandbox.
-
-`map` is a standalone CLI tool installed at `~/.vellum/bin/map`. It should already be on your PATH. If `map` is not found, prepend `PATH="$HOME/.vellum/bin:$PATH"` to the command. Do NOT search for the binary or try to discover how the CLI works. Just run the commands as documented below.
-
-## Typical Flow
-
-When the user wants to map a web service's API (e.g. "Map the Notion API" or "Figure out how Figma's API works"):
-
-1. **Ask about the objective** — Ask the user: "What service do you want to map?" and "What are you trying to build or integrate with?" This helps focus the recording on the relevant parts of the API surface.
-
-2. **Choose mode** — Ask the user: "Should I browse automatically, or do you want to drive?" This determines whether to use auto mode or manual mode:
-   - **Auto mode**: The CLI launches a headless browser, navigates the service, and records API calls automatically. Best for broad discovery.
-   - **Manual mode**: A Chrome window opens for the user to interact with the service while the CLI records all API traffic in the background. Best for capturing a specific workflow.
-
-3. **Run the mapping** — Execute the appropriate `map` command:
-   - Auto mode: `map <domain> --json`
-   - Manual mode: `map <domain> --manual --json`
-   - For longer sessions: `map <domain> --duration 120 --json`
-
-4. **Wait for recording to complete** — In auto mode, the CLI will browse and record for the default duration (60 seconds) then stop. In manual mode, the CLI blocks until the user closes the browser or presses Ctrl+C. The command outputs a JSON summary of all discovered endpoints.
-
-5. **Analyze the API map** — Review the output and present findings to the user:
-   - List discovered endpoints grouped by resource type (e.g., `/api/v1/users`, `/api/v1/documents`)
-   - Note authentication patterns (Bearer tokens, cookies, API keys)
-   - Identify CRUD operations and their HTTP methods
-   - Highlight any WebSocket or streaming endpoints
-   - Call out rate limiting headers or pagination patterns
-
-6. **Offer next steps** — Based on the discovered API surface, offer to:
-   - Create CLI tools that wrap the discovered endpoints
-   - Generate TypeScript types from observed request/response payloads
-   - Build a focused integration for the user's specific use case
-   - Re-record with a longer duration or manual mode to capture more endpoints
-
-## Important Behavior
-
-- **Be proactive.** If the user names a service, start mapping immediately rather than asking unnecessary clarifying questions. Ask about mode preference, then go.
-- **Always use `--json` flag** on all commands for reliable parsing.
-- **Present findings clearly.** Group endpoints logically, show HTTP methods, and highlight the most useful ones for the user's stated objective.
-- **Suggest manual mode for authenticated services.** If auto mode returns mostly auth redirects or login pages, suggest switching to manual mode so the user can log in first.
-- **Handle errors gracefully.** If the domain is unreachable or the recording captures no API calls, suggest checking the domain, trying manual mode, or increasing the duration.
-
-## Command Reference
-
-```
-map <domain> --json                        # Auto mode: browse and record API calls (default 60s)
-map <domain> --manual --json               # Manual mode: user drives the browser, CLI records
-map <domain> --duration <secs> --json      # Auto mode with custom duration
-map <domain> --manual --duration <secs> --json  # Manual mode with custom timeout
-```
-
-## Example Interaction
-
-**User**: "Map the Notion API"
-
-1. Ask: "What are you trying to build with Notion? And should I browse automatically, or do you want to drive the browser?"
-2. User says: "I want to build a CLI to manage my pages. I'll drive."
-3. `map notion.com --manual --json` -> Chrome window opens
-4. Tell user: "A Chrome window is open. Log into Notion and do a representative workflow — create a page, edit it, maybe move it. I'll record all API calls in the background. Close the browser when you're done."
-5. User closes browser -> CLI outputs discovered endpoints
-6. Present findings: "I found 14 API endpoints. Here are the key ones for page management:
-   - `POST /api/v3/getSpaces` — lists workspaces
-   - `POST /api/v3/syncRecordValues` — fetches page content
-   - `POST /api/v3/submitTransaction` — creates/updates pages
-   - `POST /api/v3/enqueueTask` — async operations (export, duplicate)
-   Authentication: Cookie-based session with `token_v2`."
-7. Offer: "Want me to create a CLI tool that wraps these endpoints for managing Notion pages?"

package/src/config/bundled-skills/api-mapping/icon.svg

@@ -1,18 +0,0 @@
-<svg viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg">
-  <rect width="16" height="16" fill="#0f172a"/>
-  <rect x="2" y="2" width="12" height="12" fill="#1e293b"/>
-  <rect x="3" y="3" width="10" height="10" fill="#0f172a" stroke="#3b82f6" stroke-width="1"/>
-  <rect x="4" y="4" width="2" height="2" fill="#3b82f6"/>
-  <rect x="10" y="4" width="2" height="2" fill="#3b82f6"/>
-  <rect x="4" y="10" width="2" height="2" fill="#3b82f6"/>
-  <rect x="10" y="10" width="2" height="2" fill="#3b82f6"/>
-  <line x1="5" y1="5" x2="11" y2="5" stroke="#10b981" stroke-width="1"/>
-  <line x1="5" y1="5" x2="5" y2="11" stroke="#10b981" stroke-width="1"/>
-  <line x1="11" y1="5" x2="11" y2="11" stroke="#10b981" stroke-width="1"/>
-  <line x1="5" y1="11" x2="11" y2="11" stroke="#10b981" stroke-width="1"/>
-  <rect x="7" y="7" width="2" height="2" fill="#f59e0b"/>
-  <line x1="5" y1="8" x2="7" y2="8" stroke="#60a5fa" stroke-width="1"/>
-  <line x1="9" y1="8" x2="11" y2="8" stroke="#60a5fa" stroke-width="1"/>
-  <line x1="8" y1="5" x2="8" y2="7" stroke="#60a5fa" stroke-width="1"/>
-  <line x1="8" y1="9" x2="8" y2="11" stroke="#60a5fa" stroke-width="1"/>
-</svg>

package/src/config/bundled-skills/cli-discover/SKILL.md

@@ -1,68 +0,0 @@
----
-name: cli-discover
-description: Discover which CLI tools are installed, their versions, and authentication status
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🔍","vellum":{"display-name":"CLI Discovery","user-invocable":false}}
----
-
-# CLI Discovery
-
-When you need to discover what CLI tools are available on the system, use `host_bash` to check directly. Do not use sandboxed `bash` for discovery — it may not see host-installed CLIs or auth state, leading to false negatives.
-
-## Checking if a CLI exists
-
-```bash
-which <name>        # returns path if found, exits non-zero if missing
-command -v <name>   # alternative, works in all POSIX shells
-```
-
-## Getting version info
-
-```bash
-<name> --version    # most CLIs support this flag
-```
-
-Use a 5-second timeout to avoid hanging on unresponsive CLIs.
-
-## Auth-check commands
-
-For CLIs that support authentication, check whether the user is logged in:
-
-| CLI | Auth check command |
-|-----|-------------------|
-| `gh` | `gh auth status` |
-| `aws` | `aws sts get-caller-identity` |
-| `gcloud` | `gcloud auth list --filter=status:ACTIVE --format=value(account)` |
-| `az` | `az account show` |
-| `vercel` | `vercel whoami` |
-| `netlify` | `netlify status` |
-| `fly` | `fly auth whoami` |
-| `heroku` | `heroku auth:whoami` |
-| `railway` | `railway whoami` |
-
-## Common CLIs worth checking
-
-When doing a broad discovery, check these categories:
-
-- **Version control & code hosting:** `gh`, `git`, `gitlab`
-- **Project management:** `linear`, `jira`
-- **Communication:** `slack`
-- **Cloud providers:** `aws`, `gcloud`, `az`
-- **Containers & infra:** `docker`, `kubectl`, `terraform`
-- **Runtimes & package managers:** `node`, `bun`, `deno`, `python3`, `pip3`
-- **HTTP clients:** `curl`, `httpie`
-- **Hosting & deploy:** `vercel`, `netlify`, `fly`, `heroku`, `railway`
-
-## Output format
-
-Report findings in markdown:
-
-```markdown
-## Available CLIs
-
-- **git** (/usr/bin/git) — git version 2.x.x
-- **gh** (/usr/bin/gh) — gh version 2.x.x [authenticated: user@example.com]
-- **bun** (~/.bun/bin/bun) — 1.x.x
-
-## Not found: jira, linear, slack
-```

package/src/config/bundled-skills/deploy-fullstack-vercel/SKILL.md

@@ -1,179 +0,0 @@
----
-name: deploy-fullstack-vercel
-description: Build and deploy a full-stack app (React frontend + Python/FastAPI backend) to Vercel as a serverless demo with seeded data
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🚀","vellum":{"display-name":"Deploy Fullstack to Vercel"}}
----
-
-# Deploy Fullstack to Vercel
-
-Deploy a full-stack app with a React/Vite frontend and Python/FastAPI backend to Vercel as a serverless demo. No auth required — meant for demos, portfolio pieces, and quick showcases.
-
-## When to Use
-
-- User says "deploy this to Vercel", "host this", "publish this"
-- User has a project with a frontend + backend they want live
-- User wants a quick demo deployment (no persistent database needed)
-
-## Prerequisites
-
-- A project with a frontend (React/Vite) and backend (FastAPI/Python)
-- Vercel CLI installed (`npm install -g vercel`) and authenticated (`vercel login`)
-
-## Workflow
-
-### 1. Build the Frontend
-
-```bash
-cd <project>/frontend
-npm install
-npx vite build
-```
-
-This produces static files in `frontend/dist/`.
-
-### 2. Create the Vercel Deploy Directory
-
-```
-<project>/vercel-deploy/
-├── api/
-│   ├── index.py          ← FastAPI app wrapper (entry point)
-│   ├── database.py        ← DB config (use /tmp for SQLite)
-│   ├── models.py
-│   ├── schemas.py
-│   ├── seed_data.py       ← Must seed ALL required data (users, etc.)
-│   ├── routers/
-│   │   ├── __init__.py
-│   │   └── *.py
-│   └── requirements.txt   ← Python deps (fastapi, sqlalchemy, pydantic)
-├── index.html             ← From frontend/dist/
-├── assets/                ← From frontend/dist/assets/
-└── vercel.json
-```
-
-**Key steps:**
-```bash
-mkdir -p <project>/vercel-deploy/api
-
-# Copy frontend build output to deploy root
-cp -r <project>/frontend/dist/* <project>/vercel-deploy/
-
-# Copy backend files into api/
-cp <project>/backend/models.py <project>/vercel-deploy/api/
-cp <project>/backend/database.py <project>/vercel-deploy/api/
-cp <project>/backend/schemas.py <project>/vercel-deploy/api/
-cp <project>/backend/seed_data.py <project>/vercel-deploy/api/
-cp -r <project>/backend/routers <project>/vercel-deploy/api/
-cp <project>/backend/requirements.txt <project>/vercel-deploy/api/
-```
-
-### 3. Create api/index.py (Serverless Entry Point)
-
-```python
-import sys, os
-sys.path.insert(0, os.path.dirname(__file__))
-
-from fastapi import FastAPI
-from fastapi.middleware.cors import CORSMiddleware
-from database import engine, Base, SessionLocal
-from seed_data import seed_exercises, seed_default_user  # all seed functions
-from routers import users, exercises, workouts, schedule, progress
-
-# Create tables and seed on EVERY cold start
-Base.metadata.create_all(bind=engine)
-db = SessionLocal()
-try:
-    seed_exercises(db)
-    seed_default_user(db)  # IMPORTANT: seed all required data
-finally:
-    db.close()
-
-app = FastAPI(title="MyApp")
-
-app.add_middleware(
-    CORSMiddleware,
-    allow_origins=["*"],
-    allow_credentials=True,
-    allow_methods=["*"],
-    allow_headers=["*"],
-)
-
-app.include_router(users.router)
-# ... other routers
-
-@app.get("/api/health")
-def health_check():
-    return {"status": "ok"}
-```
-
-### 4. Update database.py for Vercel
-
-**Critical:** Vercel serverless functions can only write to `/tmp`. Update the SQLite path:
-
-```python
-SQLALCHEMY_DATABASE_URL = "sqlite:////tmp/app.db"
-```
-
-### 5. Seed ALL Required Data
-
-**This is the #1 gotcha.** Since `/tmp` is ephemeral, every cold start gets a fresh database. If your frontend assumes certain data exists (like user ID 1), you MUST seed it:
-
-```python
-def seed_default_user(db: Session):
-    count = db.query(UserProfile).count()
-    if count > 0:
-        return
-    user = UserProfile(name="Demo User", ...)
-    db.add(user)
-    db.commit()
-```
-
-### 6. Create vercel.json
-
-```json
-{
-  "rewrites": [
-    { "source": "/api/(.*)", "destination": "/api/index.py" },
-    { "source": "/((?!assets/).*)", "destination": "/index.html" }
-  ]
-}
-```
-
-This routes:
-- `/api/*` → Python serverless function
-- Everything else → React SPA (index.html)
-
-### 7. Deploy
-
-```bash
-cd <project>/vercel-deploy
-vercel --yes --prod
-```
-
-### 8. Verify
-
-```bash
-curl -s <deployed-url>/api/health
-# Should return: {"status":"ok"}
-```
-
-## Gotchas & Limitations
-
-| Issue | Solution |
-|-------|----------|
-| SQLite resets on cold start | Seed ALL required data in index.py startup |
-| No persistent storage | Acceptable for demos. For production, use Vercel Postgres or Supabase |
-| No auth | Fine for demos/portfolios. Add auth layer for real apps |
-| `requirements.txt` location | Must be inside `api/` folder (next to index.py) |
-| Module imports in routers | Use `sys.path.insert(0, os.path.dirname(__file__))` in index.py |
-| CORS | Set `allow_origins=["*"]` for demo deployments |
-| `--name` flag deprecated | Don't use `--name` with Vercel CLI, just deploy from the directory |
-
-## Vercel CLI Quick Reference
-
-```bash
-npm install -g vercel    # Install
-vercel login             # Authenticate (opens browser)
-vercel --yes --prod      # Deploy to production (skip prompts)
-vercel logs --project <name>  # Check function logs
-```

package/src/config/bundled-skills/document-writer/SKILL.md

@@ -1,195 +0,0 @@
----
-name: document-writer
-description: Create and edit long-form documents like blog posts, articles, essays, and reports using the built-in rich text editor
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"📝","vellum":{"display-name":"Document Writer","user-invocable":true}}
----
-
-You are helping your user write long-form content (blog posts, articles, essays, reports, documentation) using the built-in document editor. This skill should be used whenever the user asks to write, draft, or create any document-like content.
-
-## When to Use This Skill
-
-**ALWAYS use this skill when the user asks for:**
-- Blog posts
-- Articles
-- Essays
-- Reports
-- Guides or tutorials
-- Documentation
-- Any long-form written content (500+ words)
-
-**DO NOT use this skill for:**
-- Short responses or explanations (< 500 words)
-- Code snippets or technical implementations
-- Interactive apps or dashboards (use `app_create` instead)
-- Quick summaries
-
-## Workflow
-
-### Step 1: Create the Document
-
-Use `document_create` to open the built-in rich text editor:
-
-```json
-{
-  "title": "The title of the document (inferred from user's request)",
-  "initial_content": "Optional starting content in Markdown format"
-}
-```
-
-**Important:** The editor opens in the Documents tab of the Directory panel, with chat docked to the side. The user can see both the editor and chat simultaneously.
-
-### Step 2: Generate Content
-
-Write the content in **Markdown format**. Use proper structure:
-
-- `#` for main title
-- `##` for section headings
-- `###` for subsections
-- `**bold**` and `*italic*` for emphasis
-- ` ```language ` for code blocks
-- `[text](url)` for links
-- `- ` or `1. ` for lists
-- `> ` for blockquotes
-- Tables, images, and other Markdown features as appropriate
-
-**Quality standards:**
-- Write in clear, engaging prose appropriate for the content type
-- Use active voice and vary sentence structure
-- Break content into logical sections with descriptive headings
-- Include transitions between sections
-- For technical content: use code blocks with syntax highlighting
-- For data-heavy content: use Markdown tables
-
-### Step 3: Stream Content to Editor
-
-Use `document_update` to send content to the editor as you generate it:
-
-```json
-{
-  "surface_id": "doc-xyz",
-  "content": "# Main Title\n\nYour content here...",
-  "mode": "append"
-}
-```
-
-**Streaming strategy:**
-- Generate content in logical chunks (paragraphs or sections)
-- Use `mode: "append"` to stream chunks as you write
-- The content appears in real-time in the editor
-- Don't wait to generate everything before sending - stream it!
-
-### Step 4: Handle User Edits and Requests
-
-The user can request changes via the docked chat while viewing the document:
-
-**Common requests:**
-- "Make the intro shorter"
-- "Add a section about X"
-- "Change the tone to be more formal"
-- "Fix the grammar in paragraph 3"
-
-**How to respond:**
-- Acknowledge the request
-- Generate the updated content
-- Use `document_update` with:
-  - `mode: "replace"` for complete rewrites
-  - `mode: "append"` for additions at the end
-  - For edits in the middle: use `mode: "replace"` with the full updated document
-
-### Step 5: Finalize
-
-Once the user is satisfied:
-- Confirm the document is complete
-- Remind them that it's automatically saved in the Generated panel
-- Let them know they can continue editing manually or ask for more changes
-
-## Examples
-
-### Example 1: Blog Post Request
-
-**User:** "Write a blog post about the future of AI"
-
-**Your response:**
-```
-I'll create a document for your blog post about the future of AI.
-```
-
-Then:
-1. Call `document_create` with `title: "The Future of AI"`
-2. Generate content in chunks, calling `document_update` repeatedly:
-   - First chunk: `# The Future of AI\n\nArtificial intelligence is...`
-   - Second chunk: `## Current State\n\nToday, AI systems...`
-   - Third chunk: `## Emerging Trends\n\n1. **Multimodal AI**...`
-   - Continue until complete
-
-### Example 2: Edit Request
-
-**User (after initial creation):** "Add a section about ethical considerations"
-
-**Your response:**
-```
-I'll add a section on AI ethics.
-```
-
-Then:
-1. Call `document_update` with `mode: "append"` and content:
-   ```markdown
-   ## Ethical Considerations
-
-   As AI systems become more powerful, we must address...
-   ```
-
-### Example 3: Full Rewrite
-
-**User:** "Rewrite this in a more casual tone"
-
-**Your response:**
-```
-I'll rewrite the article in a more casual, conversational tone.
-```
-
-Then:
-1. Call `document_update` with `mode: "replace"` and the complete rewritten content
-
-## Important Notes
-
-- **Documents are automatically saved** and accessible via the Generated panel
-- The user can **manually edit documents** at any time - your role is to assist with generation and refinement
-- The editor supports **drag-and-drop images**, which are converted to base64 inline
-- **Word count is tracked** automatically and displayed to the user
-- **Toast UI Editor** is used, which provides both Markdown and WYSIWYG editing modes
-- Always **acknowledge the document creation** before calling `document_create`
-
-## Error Handling
-
-- If `document_create` fails, the user may not have the client connected. Ask them to check their connection.
-- If the user asks to edit a specific part but you don't have the full document context, ask them to clarify which section or provide more context.
-- If you're unsure about the content direction, ask clarifying questions before generating.
-
-## Anti-Patterns (DO NOT DO THIS)
-
-❌ **Don't use `app_create` for blog posts or articles**
-- Blog posts should use `document_create`, not `app_create`
-- Apps are for interactive content with state/data
-
-❌ **Don't write everything at once without streaming**
-- Use `document_update` with `mode: "append"` to stream chunks
-- Users want to see content appear in real-time
-
-❌ **Don't ask for explicit approval before creating the document**
-- If the user asks for a blog post, create it immediately
-- They can always request changes after
-
-❌ **Don't output the full content in chat**
-- The content goes in the document editor, not in the chat response
-- Just acknowledge what you're doing and stream to the editor
-
-## Success Criteria
-
-✅ Document editor opens in the Documents tab
-✅ Content appears in real-time as you generate it
-✅ User can see both the editor and chat side-by-side
-✅ Content is well-structured with proper Markdown formatting
-✅ User can request edits via chat and you respond appropriately
-✅ Final document is saved and accessible in Generated panel

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

@@ -1,140 +0,0 @@
----
-name: elevenlabs-voice
-description: Select and tune an ElevenLabs TTS voice — curated voice list, custom/cloned voices via API key, and tuning parameters
-compatibility: "Designed for Vellum personal assistants"
-metadata: {"emoji":"🗣️","vellum":{"display-name":"ElevenLabs Voice","user-invocable":true}}
----
-
-## Overview
-
-ElevenLabs provides text-to-speech voices for both **in-app TTS** and **phone calls**. The shared config key `elevenlabs.voiceId` controls the voice across all channels. Use the `voice_config_update` tool to change the voice — it writes to the config file and pushes to the macOS app via SSE in one call.
-
-## Choose a Voice
-
-Pick a voice that matches the your identity and the user's preferences. Offer to show the full list if they want to choose themselves.
-
-### Female voices
-
-| Voice     | Style                      | Voice ID               |
-| --------- | -------------------------- | ---------------------- |
-| Rachel    | Calm, warm, conversational | `21m00Tcm4TlvDq8ikWAM` |
-| Sarah     | Soft, young, approachable  | `EXAVITQu4vr4xnSDxMaL` |
-| Charlotte | Warm, Swedish-accented     | `XB0fDUnXU5powFXDhCwa` |
-| Alice     | Confident, British         | `Xb7hH8MSUJpSbSDYk0k2` |
-| Matilda   | Warm, friendly, young      | `XrExE9yKIg1WjnnlVkGX` |
-| Lily      | Warm, British              | `pFZP5JQG7iQjIQuC4Bku` |
-
-### Male voices
-
-| Voice   | Style                           | Voice ID               |
-| ------- | ------------------------------- | ---------------------- |
-| Antoni  | Warm, well-rounded              | `ErXwobaYiN019PkySvjV` |
-| Josh    | Deep, young, clear              | `TxGEqnHWrfWFTfGW9XjX` |
-| Arnold  | Crisp, narrative                | `VR6AewLTigWG4xSOukaG` |
-| Adam    | Deep, middle-aged, professional | `pNInz6obpgDQGcFmaJgB` |
-| Bill    | Trustworthy, American           | `pqHfZKP75CvOlQylNhV4` |
-| George  | Warm, British, distinguished    | `JBFqnCBsd6RMkjVDRZzb` |
-| Daniel  | Authoritative, British          | `onwK4e9ZLuTAKqWW03F9` |
-| Charlie | Casual, Australian              | `IKne3meq5aSn9XLyUdCD` |
-| Liam    | Young, articulate               | `TX3LPaxmHKxFdv7VOQHJ` |
-
-### Setting the voice
-
-To set the chosen voice, use `voice_config_update`. This writes to the config file (`elevenlabs.voiceId`) for phone calls **and** pushes to the macOS app via SSE (`ttsVoiceId`) for in-app TTS in one call:
-
-```
-voice_config_update setting="tts_voice_id" value="<selected-voice-id>"
-```
-
-Verify it worked:
-
-```bash
-assistant config get elevenlabs.voiceId
-```
-
-Tell the user what voice you chose and why, but also offer to show all available voices so they can choose for themselves.
-
-## ElevenLabs API Key Setup
-
-For advanced voice selection (browsing the full library, custom/cloned voices), the user needs an ElevenLabs API key. A free tier is available at https://elevenlabs.io.
-
-To collect the API key securely:
-
-```
-credential_store action="prompt" service="elevenlabs" field="api_key"
-```
-
-## Advanced Voice Selection (with API key)
-
-Users with an ElevenLabs API key can go beyond the curated list above.
-
-### Check for an existing key
-
-```bash
-assistant credentials inspect elevenlabs:api_key --json
-```
-
-### Browse the voice library
-
-```bash
-curl -s "https://api.elevenlabs.io/v2/voices?category=premade&page_size=50" \
-  -H "xi-api-key: $(assistant credentials reveal elevenlabs:api_key)" | python3 -m json.tool
-```
-
-### Search for a specific style
-
-```bash
-curl -s "https://api.elevenlabs.io/v2/voices?search=warm+female&page_size=10" \
-  -H "xi-api-key: $(assistant credentials reveal elevenlabs:api_key)" | python3 -m json.tool
-```
-
-### Custom and cloned voices
-
-If the user has created a custom voice or voice clone in their ElevenLabs account, they can use its voice ID directly. These voices work in both in-app TTS and Twilio ConversationRelay.
-
-### Preview voices
-
-Each voice in the API response includes a `preview_url` with an audio sample the user can listen to before deciding.
-
-### Set the chosen voice
-
-After the user picks a voice from the library:
-
-```
-voice_config_update setting="tts_voice_id" value="<selected-voice-id>"
-```
-
-## Voice Tuning
-
-Fine-tune how the selected voice sounds. These parameters apply to all ElevenLabs modes (in-app TTS and phone calls):
-
-```bash
-# Playback speed (0.7 = slower, 1.0 = normal, 1.2 = faster)
-assistant config set elevenlabs.speed 1.0
-
-# Stability (0.0 = more expressive/variable, 1.0 = more consistent/monotone)
-assistant config set elevenlabs.stability 0.5
-
-# Similarity boost (0.0 = more creative, 1.0 = closer to original voice)
-assistant config set elevenlabs.similarityBoost 0.75
-```
-
-Lower stability makes the voice more expressive but less predictable — good for conversational calls. Higher stability is better for scripted or formal contexts.
-
-## Voice Model Tuning
-
-By default, the system sends a **bare** `voiceId` to Twilio ConversationRelay (no model/tuning suffix). This is the safest default across voice IDs.
-
-To optionally force Twilio's extended voice spec, set a model ID:
-
-```bash
-assistant config set elevenlabs.voiceModelId "flash_v2_5"
-```
-
-When `voiceModelId` is set, the emitted voice string becomes: `voiceId-model-speed_stability_similarity`.
-
-To clear and revert to the bare voiceId default:
-
-```bash
-assistant config set elevenlabs.voiceModelId ""
-```