conversation-launcher
The conversation-launcher skill renders a single persistent card with multiple buttons, each spawning a focused seeded conversation in the sidebar while keeping the user in the current thread. Use it to branch into multiple research directions, draft options, or triage threads without losing context; avoid it for single-destination pivots or options that should stay in one conversation.
git clone --depth 1 https://github.com/vellum-ai/vellum-assistant /tmp/conversation-launcher && cp -r /tmp/conversation-launcher/skills/conversation-launcher ~/.claude/skills/conversation-launcherSKILL.md
Use this skill when you want to offer the user several spin-off conversations from the current one. You render **one** persistent card. Each button on the card spawns its own seeded conversation in the sidebar. The user can click multiple buttons without losing their place — the origin conversation (this one) keeps focus.
## When this fits
- Research branches — "here are three angles to pursue"
- Draft choices — "here are the reply drafts I could write"
- Triaging N items — "here are the five threads with pending replies"
- Pending-reply fan-out — each sender gets their own drafting conversation
## When this does NOT fit
- Single-destination pivots — if there's one obvious next conversation, just reply inline or navigate there directly. One button is not a menu.
- Options that share context and should stay in one thread — keep them here.
- Inline Q&A the user can skim in place — answer; don't fan out.
## How to render
Emit exactly one `ui_show` call with a card shaped like this, then end your turn:
```json
{
"surface_type": "card",
"display": "inline",
"persistent": true,
"await_action": false,
"data": {
"title": "<framing headline>",
"body": "<one short sentence framing the choice>"
},
"actions": [
{
"id": "opt-1",
"label": "<short button label>",
"style": "primary",
"data": {
"_action": "launch_conversation",
"title": "<short conversation title>",
"seedPrompt": "<full first-user-message seed>",
"anchorMessageId": "<optional anchor message id from this conversation>"
}
},
{
"id": "opt-2",
"label": "<short button label>",
"style": "secondary",
"data": {
"_action": "launch_conversation",
"title": "<short conversation title>",
"seedPrompt": "<full first-user-message seed>"
}
}
]
}
```
Field notes:
- `persistent: true` keeps the card visible after a click so the user can fire more buttons.
- `await_action: false` lets the turn end without reserving the interactive-surface slot — the launcher dispatches its action directly, so blocking other surfaces is unnecessary.
- Each action's `data` must contain `_action: "launch_conversation"`, `title`, and `seedPrompt`. `anchorMessageId` is optional — include it when the spawned conversation should thread off a specific message in this one.
- `label` is the button text (short, ≤ 4 words, ≤ 30 chars). `title` is the new conversation's sidebar name (3–5 words, specific not generic). `seedPrompt` is the first user message of the new conversation — written in first-person as if the user typed it, with enough context that the new conversation can pick up without re-asking.
- Use `style: "primary"` for the recommended option (at most one), `style: "secondary"` for the rest.
## Do nothing else
After rendering the card, end your turn. The click pipeline handles everything:
- Do NOT run a follow-up step, issue any HTTP request, or write any file.
- Do NOT send a chat message after the card. The card is the response.
- Do NOT re-render the card on each click — it stays visible.
## UX contract the client enforces
- The card stays open and clickable for the lifetime of the live conversation — multiple buttons can be fired in succession without losing the user's place. If the conversation is closed and reopened later from history, the restored card reverts to single-click behavior (history rehydration drops the `persistent` flag — out of scope for this skill).
- Each `action.id` fires at most once per card lifetime; sibling actions remain clickable.
- Each spawned conversation inherits this conversation's guardian / trust context automatically.
- Sidebar focus stays on this conversation. The user sees new entries appear and can navigate in at their pace.
## Authoring tips
- Don't invent options. Only surface branches the user has actually discussed or implied.
- 2–5 buttons is the sweet spot. One option? Just reply inline. More than five? Trim or group.
- Keep the card body to one sentence. The buttons carry the payload; the body just frames the choice.
- Conversation titles should be highly concise, context-specific, and 3–5 words.>
>
>
>
Check Vellum Assistant architecture and package boundaries. Use when editing imports, moving code, adding endpoints, touching assistant/gateway/client/skill boundaries, or reviewing architecture-sensitive changes.
Review Vellum Assistant code changes for correctness, repo-specific quality rules, security risks, and missing validation. Use when reviewing diffs, preparing a PR, finishing implementation work, or when the user asks for a code review, quality pass, or pre-merge check in this repository.
Guide Vellum Assistant feature flag changes and rollout hygiene. Use when adding, editing, reviewing, or documenting assistant feature flags, rollout-gated behavior, or platform flag follow-up work.
Validate Vellum Assistant database and workspace migrations. Use when adding, editing, reviewing, or testing migrations, release-note migrations, persisted schemas, workspace file formats, or data backfills.