rivet-design 0.12.4 → 0.13.0

package/dist/utils/skills/claude-skill.js

@@ -1,98 +1,25 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.CLAUDE_SKILL_CONTENT = exports.CLAUDE_SKILL_FILENAME = exports.CLAUDE_SKILL_DIR = exports.CLAUDE_SKILL_VERSION = void 0;
-const shared_variants_protocol_1 = require("./shared-variants-protocol");
-exports.CLAUDE_SKILL_VERSION = 36;
+const cli_guidance_1 = require("./cli-guidance");
+/**
+ * Claude Code skill: CLI-first guidance written to
+ * `~/.claude/skills/rivet/SKILL.md` by `rivet install claude`. The version
+ * marker gates rewrites so user edits are only replaced by newer guidance.
+ */
+exports.CLAUDE_SKILL_VERSION = 45;
 const CLAUDE_SKILL_VERSION_MARKER = `[//]: # (rivet-skill-version: ${exports.CLAUDE_SKILL_VERSION})`;
 exports.CLAUDE_SKILL_DIR = 'rivet';
 exports.CLAUDE_SKILL_FILENAME = 'SKILL.md';
-const AGENT_VARIANTS_SECTION = (0, shared_variants_protocol_1.buildAgentVariantsSection)({
-    inChatEmphasis: 'IN THIS CHAT',
-    step9: `**Run all code-gen items IN PARALLEL.** Spawn one \`Task\` tool call per work item in a single message — they execute concurrently. Use \`subagent_type: 'general-purpose'\` for every call. Do NOT pass a skill name (e.g. \`frontend-design:frontend-design\`) as \`subagent_type\` — skills are not agent types and Task will error with "Agent type … not found". If a relevant skill is installed (e.g. \`frontend-design\`), reference it in the sub-agent's prompt body instead. Each sub-agent:
-   - Reads \`input.briefBody\` and \`input.target\`
-   - When \`input.target\` is present, scope the change to that element/file/route and its immediate section — do not restyle the rest of the page.
-   - Edits files in \`input.worktreePath\` (each variant has its own isolated worktree)
-   - Verifies the worktree diff includes CSS or markup changes before calling \`report_work_item\` (kind \`status\`) with status \`'succeeded'\`
-   - Calls \`report_work_item({ kind: 'status', sessionId, workItemId, leaseId, attempt, status: 'succeeded' })\` itself. On failure, status \`'failed'\` with error description.`,
-    step11Suffix: `When changes arrive, call \`get_pending_changes({ sessionId })\` and you'll see a \`VariantChangeItem\` in \`changes[]\`.`,
-    nativeGenLabel: 'Task sub-agents',
-});
-const CONCURRENT_REFINE_SECTION = (0, shared_variants_protocol_1.buildConcurrentRefineSection)({
-    dispatchWorker: `**Spawn a background Worker** with the \`Task\` tool (\`run_in_background: true\`, \`subagent_type: 'general-purpose'\`), passing the batch's \`workItemIds\`, the \`sessionId\`, and the \`applyGuide\` in its prompt. You (the top-level session) are the only Coordinator — sub-agents can't reliably nest, so always dispatch workers from here, never from inside a worker.`,
-    loopBack: `Then **immediately loop back to \`watch_for_changes\`** without waiting for the worker to finish — that's what lets the next change start generating while this one is still in flight.`,
-    commonMistakes: `- Running the watch loop inside a sub-agent. The coordinator MUST be the top-level session — a sub-agent can't spawn workers, so it ends up generating inline and blocking. Watch from the top level; spawn workers as sub-agents.
-- Generating variant HTML in the watch thread. You are the coordinator; you never generate. Always hand the batch to a \`run_in_background\` worker.
-- Waiting for a worker to finish before re-calling \`watch_for_changes\`. Dispatch is fire-and-forget — loop back to watch IMMEDIATELY, or the next change just sits in the queue.
-- Letting the loop die. If you stop watching (to answer a question, or after an error/interruption), the queue stops draining. Re-arm \`watch_for_changes\` as soon as you're back, and drain \`pendingVariantRequests\` first.`,
-});
 exports.CLAUDE_SKILL_CONTENT = `---
 name: rivet
-description: Rivet — explore multiple design directions for your web app ("/rivet", "use rivet variants", "explore with rivet", "create variants of X", "show me options for X", "build me a settings page from scratch", "create a new Vite todo app", "scaffold a Next.js dashboard", "open rivet", "use rivet", "make a visual change"). Pick the flow based on the user's request — see "Picking the flow" below.
+description: ${cli_guidance_1.CLI_GUIDANCE_DESCRIPTION}
 ---
 
 ${CLAUDE_SKILL_VERSION_MARKER}
+[//]: # (rivet-cli-guidance-version: ${cli_guidance_1.CLI_GUIDANCE_VERSION})
 # Rivet
 
-Rivet helps you **explore multiple design directions** for your web app. It generates parallel variants you can compare side by side, refine with the comment tool, connect design references from Pinterest or Are.na, and share or implement the direction you choose.
-
-Rivet also has a **visual editor** flow for direct point-and-click changes to a web app (including empty or HTML-only folders, which open in static mode).
-
-${shared_variants_protocol_1.RIVET_OVERVIEW}
-
-${shared_variants_protocol_1.PICKING_THE_FLOW_TABLE}
-
----
-
-${shared_variants_protocol_1.PROACTIVE_FIRST_DIRECTIONS_SECTION}
-
----
-
-## Visual Editor flow
-
-## Starting a session
-
-An **empty folder, HTML-only folder, or standalone HTML file is a valid target** — \`open_visual_editor\` detects the framework and starts the right preview backend. When the user asks for a visual / point-and-click change (or explicitly asks to just open the editor) in such a target, open the editor — do NOT refuse or reroute to variants because there's "no app yet." **First-run exception:** a bare "open rivet" / "use rivet here" with no change described, while the first-run onboarding block is present, goes to **Proactive first directions** above — propose first, do not open an empty editor.
-
-1. Call \`open_visual_editor({ projectPath })\` — pass a specific HTML file as \`projectPath\` when the user names one; otherwise pass the folder. Do NOT pass \`startPort\` or any port unless the user provided a running server.
-2. If \`opened: false\`, follow \`nextStep\` / \`nextAction\`; for \`entry_path_required\`, call \`open_visual_editor\` again with the target HTML file or \`entryPath\`.
-3. Tell the user: "Rivet is ready — make your visual changes and click 'Send to Claude Code'."
-4. Follow the structured \`nextAction\` immediately: call \`watch_for_changes({ sessionId })\` and keep the coordinator loop active until the user stops or closes the editor.
-
-## Applying changes
-
-When \`watch_for_changes\` returns, **branch on \`response.kind\` first**:
-
-- \`kind: 'static_preview_refine'\` (the user tweaked / "Vary"'d static-preview variants in the editor) → this is the concurrent path: follow **"Handling in-editor changes concurrently"** below. Do NOT run the diff-apply steps or stop-and-ask here.
-- otherwise (a plain point-and-click diff batch) → run the diff-apply steps below.
-
-For a plain diff batch (or when the user asks manually):
-
-1. \`watch_for_changes\` returns a **leased** apply batch (\`leaseId\`, \`kind: 'apply'\`). While waiting with no lease, status is \`WATCHING\` — not complete.
-2. Apply the changes to the source files listed in \`sourceFiles\`
-3. Call \`get_pending_changes({ sessionId, message: "summary of changes", refresh_git: true })\` to **ack the lease** and update the Rivet UI — only after edits land
-4. Hot reload happens automatically after file changes
-5. Tell the user what you changed
-6. Immediately call \`watch_for_changes({ sessionId })\` again unless the user explicitly asks you to stop or close the editor
-
-${shared_variants_protocol_1.DURABLE_BATCH_HANDOFF_SECTION}
-
-## Ending a session
-
-When the user says they're done, call \`close_visual_editor({ sessionId })\`.
-
-## Rules
-
-- Call \`open_visual_editor\` directly; it detects the project and starts the preview backend
-- **Always use \`watch_for_changes\`** to wait for user changes — do NOT use Monitor, background shell commands, or manual polling. After a successful open, the structured \`nextAction\` is required and immediate.
-- **Never auto-commit** after applying visual changes — let the user decide
-- The dev server stays running after \`close_visual_editor\`
-
----
-
-${CONCURRENT_REFINE_SECTION}
-
----
-
-${AGENT_VARIANTS_SECTION}
+${cli_guidance_1.CLI_GUIDANCE_BODY}
 `;
 //# sourceMappingURL=claude-skill.js.map

package/dist/utils/skills/claude-skill.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-skill.js","sourceRoot":"","sources":["../../../src/utils/skills/claude-skill.ts"],"names":[],"mappings":";;;AAAA,yEAOoC;AAEvB,QAAA,oBAAoB,GAAG,EAAE,CAAC;AACvC,MAAM,2BAA2B,GAAG,iCAAiC,4BAAoB,GAAG,CAAC;AAEhF,QAAA,gBAAgB,GAAG,OAAO,CAAC;AAC3B,QAAA,qBAAqB,GAAG,UAAU,CAAC;AAEhD,MAAM,sBAAsB,GAAG,IAAA,oDAAyB,EAAC;IACvD,cAAc,EAAE,cAAc;IAC9B,KAAK,EAAE;;;;;kLAKyK;IAChL,YAAY,EAAE,2HAA2H;IACzI,cAAc,EAAE,iBAAiB;CAClC,CAAC,CAAC;AAEH,MAAM,yBAAyB,GAAG,IAAA,uDAA4B,EAAC;IAC7D,cAAc,EAAE,kXAAkX;IAClY,QAAQ,EAAE,yLAAyL;IACnM,cAAc,EAAE;;;gOAG8M;CAC/N,CAAC,CAAC;AAEU,QAAA,oBAAoB,GAAG;;;;;EAKlC,2BAA2B;;;;;;;EAO3B,yCAAc;;EAEd,iDAAsB;;;;EAItB,6DAAkC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA+BlC,wDAA6B;;;;;;;;;;;;;;;EAe7B,yBAAyB;;;;EAIzB,sBAAsB;CACvB,CAAC"}
+{"version":3,"file":"claude-skill.js","sourceRoot":"","sources":["../../../src/utils/skills/claude-skill.ts"],"names":[],"mappings":";;;AAAA,iDAIwB;AAExB;;;;GAIG;AAEU,QAAA,oBAAoB,GAAG,EAAE,CAAC;AACvC,MAAM,2BAA2B,GAAG,iCAAiC,4BAAoB,GAAG,CAAC;AAEhF,QAAA,gBAAgB,GAAG,OAAO,CAAC;AAC3B,QAAA,qBAAqB,GAAG,UAAU,CAAC;AAEnC,QAAA,oBAAoB,GAAG;;eAErB,uCAAwB;;;EAGrC,2BAA2B;uCACU,mCAAoB;;;EAGzD,gCAAiB;CAClB,CAAC"}

package/dist/utils/skills/cli-guidance.d.ts

@@ -0,0 +1,12 @@
+/**
+ * Shared CLI-first agent guidance. Each host's install artifact (Claude
+ * skill, Cursor rules, Codex AGENTS.md section) wraps this body in its own
+ * frontmatter. The `rivet` binary is self-teaching too — `rivet --help`
+ * states the same contract — because guidance files are softer than
+ * registration: an agent can ignore them.
+ */
+export declare const CLI_GUIDANCE_VERSION = 12;
+export declare const CLI_GUIDANCE_BODY = "Rivet helps you **explore multiple design directions** for a web app. You drive it by running `rivet` CLI commands. Every command prints exactly one JSON envelope on stdout (`{ schemaVersion, ok, command, data | error }`), routes progress to stderr, and never prompts for input.\n\n**Exit codes:** 0 ok \u00B7 1 operation failed (see `error.code`) \u00B7 2 usage error \u00B7 3 auth required \u00B7 4 no server for the project \u00B7 5 `rivet wait` timeout (work still pending or running \u2014 not a failure; the envelope's `state` says which).\n\n**Identify yourself (handoff).** Add these flags to every invocation so Rivet can attribute work: `--caller-agent claude|codex|cursor`, `--caller-model <your model>`, and `--caller-session <your chat session id>` when you have one. Human-direct invocations omit handoff flags. Never wrap or chain `rivet` with other commands (`&&`, pipes) \u2014 plain invocations are what the host allowlist covers.\n\n**Project path.** Prefer explicit `--project <absolute path>` on every command so follow-up chats attach to the same workspace. For an existing app, pass its repo/app root. For a fresh app, create or use an empty directory first, then open Rivet there and start variants with `--fresh`.\n\n**Browser behavior.** For interactive user workflows, run `rivet open` without `--no-browser` so the Rivet UI opens in the browser. Use `--no-browser` only for headless/background automation, CI/e2e checks, or when the user explicitly asks not to open a browser; in those cases, report the returned `editorUrl`.\n\n**MCP tools (opt-in).** If this host has Rivet MCP tools registered (`rivet_status`, `rivet_variants`, `rivet_design_context` \u2014 the user opted in via `rivet install --mcp`), prefer them over shelling out for status, variants, and design-context work: they drive the same control plane and return the same JSON envelopes, without per-call process cost. Lifecycle and auth stay CLI-only on purpose \u2014 `rivet open`, `rivet stop`, `rivet wait`, and `rivet login` have no MCP tools. There is no blocking/watch tool either: start work with `rivet_variants`; if the result contains `nextAction.action=\"complete_host_variant_work\"`, execute it yourself with parallel subagents when available.\n\n## Commands\n\n- `rivet open [--project <path>] [--agent claude|codex|cursor] [--rivet-port N] [--user-port N] [--framework nextjs|vite|cra|remix|svelte|static] [--entry <path>] [--no-browser] [--no-git]` \u2014 start or attach the project's editor server (idempotent; returns `editorUrl`). It detects the app, attaches to an already-running dev server, or starts one from the app's standard `dev`/`start`/`serve` script when possible. Omit `--no-browser` for interactive work so the UI opens for the user.\n- `rivet variants start --project <path> --instruction <text> [--count N] [--element <selector>] [--fresh] [--target <sessionId>:<variantId>]` \u2014 explore design directions. Use `--fresh` for prompt-only 0-to-1 generation in a blank/new workspace; use `--target` to Vary an existing direction. Returns a `workId` immediately, plus `nextAction` when the host agent should implement the variants.\n- `rivet variants complete <workId> --project <path> [--session <sessionId>] [--status succeeded|failed|cancelled] [--output <json>] [--error <message>]` \u2014 report one host-agent work item complete after you edit its worktree.\n- `rivet wait <workId> --project <path> [--timeout <seconds>]` \u2014 bounded block until a work id settles (exit 5 on timeout; re-issue or check status).\n- `rivet status --project <path> [--watch]` \u2014 session, resolved runner, active run, and the variants snapshot. `--watch` streams NDJSON.\n- `rivet variants status --project <path>` / `rivet variants list --project <path> [--history]` \u2014 inspect live or past directions.\n- `rivet variants commit <variantId> --project <path> [--session <id>]` \u2014 send the chosen direction to the project.\n- `rivet variants cancel <sessionId> --project <path>` \u2014 cancel a running variants session.\n- `rivet evidence capture --url <url>` \u2014 rendered design evidence (root variables, element styles, fonts) for a reference URL.\n- `rivet reference fetch <url>` \u2014 Pinterest / Are.na reference data via the user's connected account.\n- `rivet auth status` \u2014 signed-in state. If `authenticated: false`, tell the user to run `rivet login` themselves \u2014 never run login for them.\n- `rivet stop [--project <path>]` \u2014 stop the CLI-owned server.\n\n## Typical flows\n\nExisting app:\n1. `rivet open --project <path> --caller-agent cursor --caller-model <model> --caller-session <id>` \u2192 note `editorUrl`, `sessionId`, and `resolvedRunner`.\n2. `rivet variants start --project <path> --instruction \"try three hero layouts\" --count 3 --caller-agent cursor --caller-model <model> --caller-session <id>` \u2192 note `workId`.\n3. If the start response has `nextAction.action=\"complete_host_variant_work\"`, execute it immediately. Otherwise poll `rivet status --project <path>` until that `nextAction` appears. The work items are independent: when your host supports subagents or parallel tasks, spawn one worker per item, each editing only its own `worktreePath` according to `briefLabel`, `briefBody`, target, and project context. Follow the item's `outputSchema`.\n4. As each worker finishes, run `rivet variants complete <workId> --project <path> --session <sessionId> --output '{\"worktreePath\":\"<worktreePath>\",\"changedFiles\":[\"relative/path\"]}'`. If a worker cannot complete it, use `--status failed --error <message>`.\n5. Show the user the `editorUrl` to compare directions; `rivet variants commit <variantId> --project <path>` when they pick one.\n\nFresh 0-to-1: create or use an empty directory, run `rivet open --project <path> ...`, then `rivet variants start --project <path> --fresh --instruction \"build a SaaS landing page\" --count 3 ...`.\n\nVary an existing direction: after status/list gives you `sessionId` and `variantId`, run `rivet variants start --project <path> --target <sessionId>:<variantId> --instruction \"make this calmer\" --count 2 ...`.\n\nRivet owns orchestration; the host agent owns implementation. Do not wait for Rivet to spawn a separate agent. When `rivet variants start`, `rivet status`, `rivet_variants`, or `rivet_status` returns `nextAction.action=\"complete_host_variant_work\"`, complete those work items from the current host session. Prefer parallelism: use one subagent or parallel task per work item when the host supports it, because each item has an isolated worktree. Report each item with `rivet variants complete` or `rivet_variants` action `complete`.\n\n**Never cancel to unblock.** If `variants start` is rejected with `start_in_flight`, a start is still provisioning (status reports `variants.starting: true` \u2014 can take minutes); poll status and retry once it clears. If rejected with `active_session`, the user has live work: report the conflict and let them decide, or refine the active session with `--target`. Cancelling a session destroys the user's in-progress exploration \u2014 only do it when the user explicitly asks.";
+/** One-line description used in host frontmatter/description fields. */
+export declare const CLI_GUIDANCE_DESCRIPTION = "Rivet \u2014 explore multiple design directions for your web app (\"/rivet\", \"use rivet\", \"explore with rivet\", \"create variants of X\", \"show me options for X\", \"open rivet\", \"open the visual editor\"). Drive it with `rivet` CLI commands.";
+//# sourceMappingURL=cli-guidance.d.ts.map

package/dist/utils/skills/cli-guidance.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli-guidance.d.ts","sourceRoot":"","sources":["../../../src/utils/skills/cli-guidance.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,eAAO,MAAM,oBAAoB,KAAK,CAAC;AAEvC,eAAO,MAAM,iBAAiB,ygOA0Cmc,CAAC;AAEle,wEAAwE;AACxE,eAAO,MAAM,wBAAwB,+PACsM,CAAC"}

package/dist/utils/skills/cli-guidance.js

@@ -0,0 +1,57 @@
+"use strict";
+/**
+ * Shared CLI-first agent guidance. Each host's install artifact (Claude
+ * skill, Cursor rules, Codex AGENTS.md section) wraps this body in its own
+ * frontmatter. The `rivet` binary is self-teaching too — `rivet --help`
+ * states the same contract — because guidance files are softer than
+ * registration: an agent can ignore them.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.CLI_GUIDANCE_DESCRIPTION = exports.CLI_GUIDANCE_BODY = exports.CLI_GUIDANCE_VERSION = void 0;
+exports.CLI_GUIDANCE_VERSION = 12;
+exports.CLI_GUIDANCE_BODY = `Rivet helps you **explore multiple design directions** for a web app. You drive it by running \`rivet\` CLI commands. Every command prints exactly one JSON envelope on stdout (\`{ schemaVersion, ok, command, data | error }\`), routes progress to stderr, and never prompts for input.
+
+**Exit codes:** 0 ok · 1 operation failed (see \`error.code\`) · 2 usage error · 3 auth required · 4 no server for the project · 5 \`rivet wait\` timeout (work still pending or running — not a failure; the envelope's \`state\` says which).
+
+**Identify yourself (handoff).** Add these flags to every invocation so Rivet can attribute work: \`--caller-agent claude|codex|cursor\`, \`--caller-model <your model>\`, and \`--caller-session <your chat session id>\` when you have one. Human-direct invocations omit handoff flags. Never wrap or chain \`rivet\` with other commands (\`&&\`, pipes) — plain invocations are what the host allowlist covers.
+
+**Project path.** Prefer explicit \`--project <absolute path>\` on every command so follow-up chats attach to the same workspace. For an existing app, pass its repo/app root. For a fresh app, create or use an empty directory first, then open Rivet there and start variants with \`--fresh\`.
+
+**Browser behavior.** For interactive user workflows, run \`rivet open\` without \`--no-browser\` so the Rivet UI opens in the browser. Use \`--no-browser\` only for headless/background automation, CI/e2e checks, or when the user explicitly asks not to open a browser; in those cases, report the returned \`editorUrl\`.
+
+**MCP tools (opt-in).** If this host has Rivet MCP tools registered (\`rivet_status\`, \`rivet_variants\`, \`rivet_design_context\` — the user opted in via \`rivet install --mcp\`), prefer them over shelling out for status, variants, and design-context work: they drive the same control plane and return the same JSON envelopes, without per-call process cost. Lifecycle and auth stay CLI-only on purpose — \`rivet open\`, \`rivet stop\`, \`rivet wait\`, and \`rivet login\` have no MCP tools. There is no blocking/watch tool either: start work with \`rivet_variants\`; if the result contains \`nextAction.action="complete_host_variant_work"\`, execute it yourself with parallel subagents when available.
+
+## Commands
+
+- \`rivet open [--project <path>] [--agent claude|codex|cursor] [--rivet-port N] [--user-port N] [--framework nextjs|vite|cra|remix|svelte|static] [--entry <path>] [--no-browser] [--no-git]\` — start or attach the project's editor server (idempotent; returns \`editorUrl\`). It detects the app, attaches to an already-running dev server, or starts one from the app's standard \`dev\`/\`start\`/\`serve\` script when possible. Omit \`--no-browser\` for interactive work so the UI opens for the user.
+- \`rivet variants start --project <path> --instruction <text> [--count N] [--element <selector>] [--fresh] [--target <sessionId>:<variantId>]\` — explore design directions. Use \`--fresh\` for prompt-only 0-to-1 generation in a blank/new workspace; use \`--target\` to Vary an existing direction. Returns a \`workId\` immediately, plus \`nextAction\` when the host agent should implement the variants.
+- \`rivet variants complete <workId> --project <path> [--session <sessionId>] [--status succeeded|failed|cancelled] [--output <json>] [--error <message>]\` — report one host-agent work item complete after you edit its worktree.
+- \`rivet wait <workId> --project <path> [--timeout <seconds>]\` — bounded block until a work id settles (exit 5 on timeout; re-issue or check status).
+- \`rivet status --project <path> [--watch]\` — session, resolved runner, active run, and the variants snapshot. \`--watch\` streams NDJSON.
+- \`rivet variants status --project <path>\` / \`rivet variants list --project <path> [--history]\` — inspect live or past directions.
+- \`rivet variants commit <variantId> --project <path> [--session <id>]\` — send the chosen direction to the project.
+- \`rivet variants cancel <sessionId> --project <path>\` — cancel a running variants session.
+- \`rivet evidence capture --url <url>\` — rendered design evidence (root variables, element styles, fonts) for a reference URL.
+- \`rivet reference fetch <url>\` — Pinterest / Are.na reference data via the user's connected account.
+- \`rivet auth status\` — signed-in state. If \`authenticated: false\`, tell the user to run \`rivet login\` themselves — never run login for them.
+- \`rivet stop [--project <path>]\` — stop the CLI-owned server.
+
+## Typical flows
+
+Existing app:
+1. \`rivet open --project <path> --caller-agent cursor --caller-model <model> --caller-session <id>\` → note \`editorUrl\`, \`sessionId\`, and \`resolvedRunner\`.
+2. \`rivet variants start --project <path> --instruction "try three hero layouts" --count 3 --caller-agent cursor --caller-model <model> --caller-session <id>\` → note \`workId\`.
+3. If the start response has \`nextAction.action="complete_host_variant_work"\`, execute it immediately. Otherwise poll \`rivet status --project <path>\` until that \`nextAction\` appears. The work items are independent: when your host supports subagents or parallel tasks, spawn one worker per item, each editing only its own \`worktreePath\` according to \`briefLabel\`, \`briefBody\`, target, and project context. Follow the item's \`outputSchema\`.
+4. As each worker finishes, run \`rivet variants complete <workId> --project <path> --session <sessionId> --output '{"worktreePath":"<worktreePath>","changedFiles":["relative/path"]}'\`. If a worker cannot complete it, use \`--status failed --error <message>\`.
+5. Show the user the \`editorUrl\` to compare directions; \`rivet variants commit <variantId> --project <path>\` when they pick one.
+
+Fresh 0-to-1: create or use an empty directory, run \`rivet open --project <path> ...\`, then \`rivet variants start --project <path> --fresh --instruction "build a SaaS landing page" --count 3 ...\`.
+
+Vary an existing direction: after status/list gives you \`sessionId\` and \`variantId\`, run \`rivet variants start --project <path> --target <sessionId>:<variantId> --instruction "make this calmer" --count 2 ...\`.
+
+Rivet owns orchestration; the host agent owns implementation. Do not wait for Rivet to spawn a separate agent. When \`rivet variants start\`, \`rivet status\`, \`rivet_variants\`, or \`rivet_status\` returns \`nextAction.action="complete_host_variant_work"\`, complete those work items from the current host session. Prefer parallelism: use one subagent or parallel task per work item when the host supports it, because each item has an isolated worktree. Report each item with \`rivet variants complete\` or \`rivet_variants\` action \`complete\`.
+
+**Never cancel to unblock.** If \`variants start\` is rejected with \`start_in_flight\`, a start is still provisioning (status reports \`variants.starting: true\` — can take minutes); poll status and retry once it clears. If rejected with \`active_session\`, the user has live work: report the conflict and let them decide, or refine the active session with \`--target\`. Cancelling a session destroys the user's in-progress exploration — only do it when the user explicitly asks.`;
+/** One-line description used in host frontmatter/description fields. */
+exports.CLI_GUIDANCE_DESCRIPTION = 'Rivet — explore multiple design directions for your web app ("/rivet", "use rivet", "explore with rivet", "create variants of X", "show me options for X", "open rivet", "open the visual editor"). Drive it with `rivet` CLI commands.';
+//# sourceMappingURL=cli-guidance.js.map

package/dist/utils/skills/cli-guidance.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli-guidance.js","sourceRoot":"","sources":["../../../src/utils/skills/cli-guidance.ts"],"names":[],"mappings":";AAAA;;;;;;GAMG;;;AAEU,QAAA,oBAAoB,GAAG,EAAE,CAAC;AAE1B,QAAA,iBAAiB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ieA0Cgc,CAAC;AAEle,wEAAwE;AAC3D,QAAA,wBAAwB,GACnC,yOAAyO,CAAC"}

package/dist/utils/skills/cursor-rules.d.ts

@@ -1,4 +1,10 @@
-export declare const CURSOR_RULES_VERSION = 35;
+/**
+ * Cursor project rules: CLI-first guidance written to
+ * `<project>/.cursor/rules/rivet.mdc` when the editor opens a project
+ * (project scope is where Cursor reads rules files from; the user-scope
+ * install writes the command allowlist instead).
+ */
+export declare const CURSOR_RULES_VERSION = 44;
 export declare const CURSOR_RULES_FILENAME = "rivet.mdc";
-export declare const CURSOR_RULES_CONTENT: string;
+export declare const CURSOR_RULES_CONTENT = "---\ndescription: Rivet \u2014 explore multiple design directions for your web app (\"/rivet\", \"use rivet\", \"explore with rivet\", \"create variants of X\", \"show me options for X\", \"open rivet\", \"open the visual editor\"). Drive it with `rivet` CLI commands.\nalwaysApply: false\n---\n<!-- rivet-rules-version: 44 -->\n<!-- rivet-cli-guidance-version: 12 -->\n# Rivet\n\nRivet helps you **explore multiple design directions** for a web app. You drive it by running `rivet` CLI commands. Every command prints exactly one JSON envelope on stdout (`{ schemaVersion, ok, command, data | error }`), routes progress to stderr, and never prompts for input.\n\n**Exit codes:** 0 ok \u00B7 1 operation failed (see `error.code`) \u00B7 2 usage error \u00B7 3 auth required \u00B7 4 no server for the project \u00B7 5 `rivet wait` timeout (work still pending or running \u2014 not a failure; the envelope's `state` says which).\n\n**Identify yourself (handoff).** Add these flags to every invocation so Rivet can attribute work: `--caller-agent claude|codex|cursor`, `--caller-model <your model>`, and `--caller-session <your chat session id>` when you have one. Human-direct invocations omit handoff flags. Never wrap or chain `rivet` with other commands (`&&`, pipes) \u2014 plain invocations are what the host allowlist covers.\n\n**Project path.** Prefer explicit `--project <absolute path>` on every command so follow-up chats attach to the same workspace. For an existing app, pass its repo/app root. For a fresh app, create or use an empty directory first, then open Rivet there and start variants with `--fresh`.\n\n**Browser behavior.** For interactive user workflows, run `rivet open` without `--no-browser` so the Rivet UI opens in the browser. Use `--no-browser` only for headless/background automation, CI/e2e checks, or when the user explicitly asks not to open a browser; in those cases, report the returned `editorUrl`.\n\n**MCP tools (opt-in).** If this host has Rivet MCP tools registered (`rivet_status`, `rivet_variants`, `rivet_design_context` \u2014 the user opted in via `rivet install --mcp`), prefer them over shelling out for status, variants, and design-context work: they drive the same control plane and return the same JSON envelopes, without per-call process cost. Lifecycle and auth stay CLI-only on purpose \u2014 `rivet open`, `rivet stop`, `rivet wait`, and `rivet login` have no MCP tools. There is no blocking/watch tool either: start work with `rivet_variants`; if the result contains `nextAction.action=\"complete_host_variant_work\"`, execute it yourself with parallel subagents when available.\n\n## Commands\n\n- `rivet open [--project <path>] [--agent claude|codex|cursor] [--rivet-port N] [--user-port N] [--framework nextjs|vite|cra|remix|svelte|static] [--entry <path>] [--no-browser] [--no-git]` \u2014 start or attach the project's editor server (idempotent; returns `editorUrl`). It detects the app, attaches to an already-running dev server, or starts one from the app's standard `dev`/`start`/`serve` script when possible. Omit `--no-browser` for interactive work so the UI opens for the user.\n- `rivet variants start --project <path> --instruction <text> [--count N] [--element <selector>] [--fresh] [--target <sessionId>:<variantId>]` \u2014 explore design directions. Use `--fresh` for prompt-only 0-to-1 generation in a blank/new workspace; use `--target` to Vary an existing direction. Returns a `workId` immediately, plus `nextAction` when the host agent should implement the variants.\n- `rivet variants complete <workId> --project <path> [--session <sessionId>] [--status succeeded|failed|cancelled] [--output <json>] [--error <message>]` \u2014 report one host-agent work item complete after you edit its worktree.\n- `rivet wait <workId> --project <path> [--timeout <seconds>]` \u2014 bounded block until a work id settles (exit 5 on timeout; re-issue or check status).\n- `rivet status --project <path> [--watch]` \u2014 session, resolved runner, active run, and the variants snapshot. `--watch` streams NDJSON.\n- `rivet variants status --project <path>` / `rivet variants list --project <path> [--history]` \u2014 inspect live or past directions.\n- `rivet variants commit <variantId> --project <path> [--session <id>]` \u2014 send the chosen direction to the project.\n- `rivet variants cancel <sessionId> --project <path>` \u2014 cancel a running variants session.\n- `rivet evidence capture --url <url>` \u2014 rendered design evidence (root variables, element styles, fonts) for a reference URL.\n- `rivet reference fetch <url>` \u2014 Pinterest / Are.na reference data via the user's connected account.\n- `rivet auth status` \u2014 signed-in state. If `authenticated: false`, tell the user to run `rivet login` themselves \u2014 never run login for them.\n- `rivet stop [--project <path>]` \u2014 stop the CLI-owned server.\n\n## Typical flows\n\nExisting app:\n1. `rivet open --project <path> --caller-agent cursor --caller-model <model> --caller-session <id>` \u2192 note `editorUrl`, `sessionId`, and `resolvedRunner`.\n2. `rivet variants start --project <path> --instruction \"try three hero layouts\" --count 3 --caller-agent cursor --caller-model <model> --caller-session <id>` \u2192 note `workId`.\n3. If the start response has `nextAction.action=\"complete_host_variant_work\"`, execute it immediately. Otherwise poll `rivet status --project <path>` until that `nextAction` appears. The work items are independent: when your host supports subagents or parallel tasks, spawn one worker per item, each editing only its own `worktreePath` according to `briefLabel`, `briefBody`, target, and project context. Follow the item's `outputSchema`.\n4. As each worker finishes, run `rivet variants complete <workId> --project <path> --session <sessionId> --output '{\"worktreePath\":\"<worktreePath>\",\"changedFiles\":[\"relative/path\"]}'`. If a worker cannot complete it, use `--status failed --error <message>`.\n5. Show the user the `editorUrl` to compare directions; `rivet variants commit <variantId> --project <path>` when they pick one.\n\nFresh 0-to-1: create or use an empty directory, run `rivet open --project <path> ...`, then `rivet variants start --project <path> --fresh --instruction \"build a SaaS landing page\" --count 3 ...`.\n\nVary an existing direction: after status/list gives you `sessionId` and `variantId`, run `rivet variants start --project <path> --target <sessionId>:<variantId> --instruction \"make this calmer\" --count 2 ...`.\n\nRivet owns orchestration; the host agent owns implementation. Do not wait for Rivet to spawn a separate agent. When `rivet variants start`, `rivet status`, `rivet_variants`, or `rivet_status` returns `nextAction.action=\"complete_host_variant_work\"`, complete those work items from the current host session. Prefer parallelism: use one subagent or parallel task per work item when the host supports it, because each item has an isolated worktree. Report each item with `rivet variants complete` or `rivet_variants` action `complete`.\n\n**Never cancel to unblock.** If `variants start` is rejected with `start_in_flight`, a start is still provisioning (status reports `variants.starting: true` \u2014 can take minutes); poll status and retry once it clears. If rejected with `active_session`, the user has live work: report the conflict and let them decide, or refine the active session with `--target`. Cancelling a session destroys the user's in-progress exploration \u2014 only do it when the user explicitly asks.\n";
 //# sourceMappingURL=cursor-rules.d.ts.map

package/dist/utils/skills/cursor-rules.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cursor-rules.d.ts","sourceRoot":"","sources":["../../../src/utils/skills/cursor-rules.ts"],"names":[],"mappings":"AASA,eAAO,MAAM,oBAAoB,KAAK,CAAC;AACvC,eAAO,MAAM,qBAAqB,cAAc,CAAC;AAuBjD,eAAO,MAAM,oBAAoB,QAkEhC,CAAC"}
+{"version":3,"file":"cursor-rules.d.ts","sourceRoot":"","sources":["../../../src/utils/skills/cursor-rules.ts"],"names":[],"mappings":"AAMA;;;;;GAKG;AAEH,eAAO,MAAM,oBAAoB,KAAK,CAAC;AACvC,eAAO,MAAM,qBAAqB,cAAc,CAAC;AAGjD,eAAO,MAAM,oBAAoB,w4OAShC,CAAC"}

package/dist/utils/skills/cursor-rules.js

@@ -1,93 +1,24 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.CURSOR_RULES_CONTENT = exports.CURSOR_RULES_FILENAME = exports.CURSOR_RULES_VERSION = void 0;
-const shared_variants_protocol_1 = require("./shared-variants-protocol");
-exports.CURSOR_RULES_VERSION = 35;
+const cli_guidance_1 = require("./cli-guidance");
+/**
+ * Cursor project rules: CLI-first guidance written to
+ * `<project>/.cursor/rules/rivet.mdc` when the editor opens a project
+ * (project scope is where Cursor reads rules files from; the user-scope
+ * install writes the command allowlist instead).
+ */
+exports.CURSOR_RULES_VERSION = 44;
 exports.CURSOR_RULES_FILENAME = 'rivet.mdc';
 const CURSOR_RULES_VERSION_MARKER = `rivet-rules-version: ${exports.CURSOR_RULES_VERSION}`;
-const AGENT_VARIANTS_SECTION = (0, shared_variants_protocol_1.buildAgentVariantsSection)({
-    inChatEmphasis: 'in chat',
-    step9: `**Run all code-gen items IN PARALLEL** via parallel tool calls in a single response. For each:
-   - Read \`input.briefBody\` and \`input.target\`
-   - When \`input.target\` is present, scope the change to that element/file/route and its immediate section — do not restyle the rest of the page.
-   - Edit files in \`input.worktreePath\` (each variant has its own isolated worktree)
-   - Verify the worktree diff includes CSS or markup changes before calling \`report_work_item\` (kind \`status\`) with status \`'succeeded'\` — empty or deletion-only diffs fail QA.
-   - Call \`report_work_item({ kind: 'status', sessionId, workItemId, leaseId, attempt, status: 'succeeded' })\`. On failure, status \`'failed'\` with error description.`,
-    step11Suffix: `When \`hasChanges: true\`, you'll see a \`VariantChangeItem\` in \`changes[]\`.`,
-    nativeGenLabel: 'Task tool',
-});
-const CONCURRENT_REFINE_SECTION = (0, shared_variants_protocol_1.buildConcurrentRefineSection)({
-    dispatchWorker: `Cursor has no backgroundable sub-agents, so act as the Worker inline: lease the batch via \`continue_variants({ action: 'request_work', workItemIds })\` and generate its items via parallel tool calls in one response, following \`applyGuide\`.`,
-    loopBack: `Then loop back to \`watch_for_changes\` for the next batch. Per-batch \`workItemIds\` leasing keeps concurrent batches isolated even though you generate one batch at a time — never lease with a bare count, which would greedily grab another batch's work.`,
-    commonMistakes: `- Leasing with a bare count instead of the batch's \`workItemIds\`. That greedily grabs another batch's work and breaks isolation — always lease the exact \`workItemIds\`.
-- Forgetting to loop back to \`watch_for_changes\` after a batch. Cursor generates one batch at a time (no background sub-agents), so the loop is the only thing that picks up the next change — return to watch as soon as the batch is reported.
-- Going idle after answering an unrelated question. Re-arm \`watch_for_changes\` whenever you return to the session, and drain any \`pendingVariantRequests\` first.`,
-});
 exports.CURSOR_RULES_CONTENT = `---
-description: Rivet — explore multiple design directions for your web app ("/rivet", "use rivet variants", "explore with rivet", "create variants", "show me options for X", "build me X from scratch", "create a new Y app", "open rivet", "open the visual editor")
+description: ${cli_guidance_1.CLI_GUIDANCE_DESCRIPTION}
 alwaysApply: false
 ---
 <!-- ${CURSOR_RULES_VERSION_MARKER} -->
+<!-- rivet-cli-guidance-version: ${cli_guidance_1.CLI_GUIDANCE_VERSION} -->
 # Rivet
 
-Rivet helps you **explore multiple design directions** for your web app. It generates parallel variants you can compare side by side, refine with the comment tool, connect design references from Pinterest or Are.na, and share or implement the direction you choose.
-
-Rivet also has a **visual editor** flow for direct point-and-click changes to a web app (including empty or HTML-only folders, which open in static mode).
-
-> Tip: type \`@rivet.mdc\` in chat to invoke this rule manually.
-
-${shared_variants_protocol_1.RIVET_OVERVIEW}
-
-${shared_variants_protocol_1.PICKING_THE_FLOW_TABLE}
-
----
-
-${shared_variants_protocol_1.PROACTIVE_FIRST_DIRECTIONS_SECTION}
-
----
-
-## Visual Editor flow
-
-## Starting a session
-
-An **empty folder, HTML-only folder, or standalone HTML file is a valid target** — \`open_visual_editor\` detects the framework and starts the right preview backend. When the user asks for a visual / point-and-click change (or explicitly asks to just open the editor) in such a target, open the editor — do NOT refuse or reroute to variants because there's "no app yet." **First-run exception:** a bare "open rivet" / "use rivet here" with no change described, while the first-run onboarding block is present, goes to **Proactive first directions** above — propose first, do not open an empty editor.
-
-1. Call \`open_visual_editor({ projectPath })\` — pass a specific HTML file as \`projectPath\` when the user names one; otherwise pass the folder. Do NOT pass \`startPort\` or any port unless the user provided a running server.
-2. If \`opened: false\`, follow \`nextStep\` / \`nextAction\`; for \`entry_path_required\`, call \`open_visual_editor\` again with the target HTML file or \`entryPath\`.
-3. Tell the user: "Rivet is ready — make your visual changes and click 'Send to Cursor'."
-4. Follow the structured \`nextAction\` immediately: call \`watch_for_changes({ sessionId })\` and keep the loop active until the user stops or closes the editor.
-
-## Watching and applying
-
-1. Call \`watch_for_changes({ sessionId })\` — blocks until the user clicks "Send to Cursor". Bridge status becomes \`WATCHING\` while waiting — that is **not** round complete.
-2. If it times out (\`hasChanges: false\`), call it again to keep waiting
-3. **Branch on \`response.kind\`:** \`kind: 'static_preview_refine'\` (static-preview variant tweaks / "Vary"s) → follow **"Handling in-editor changes concurrently"** below instead of the steps here. Otherwise (plain point-and-click diff) → continue with step 4.
-4. When \`hasChanges: true\`, you received a **leased** batch (\`leaseId\`, \`kind: 'apply'\`). Apply the changes to the source files listed in \`sourceFiles\`
-5. Call \`get_pending_changes({ sessionId, message: "summary of changes", refresh_git: true })\` to **ack the lease** and update the Rivet UI — do this only after edits land
-6. Hot reload happens automatically after file changes
-7. Tell the user what you changed
-8. Immediately call \`watch_for_changes({ sessionId })\` again unless the user explicitly asks you to stop or close the editor
-
-${shared_variants_protocol_1.DURABLE_BATCH_HANDOFF_SECTION}
-
-## Ending a session
-
-When the user says they're done, call \`close_visual_editor({ sessionId })\`.
-
-## Rules
-
-- Call \`open_visual_editor\` directly; it detects the project and starts the preview backend
-- **Always use \`watch_for_changes\`** to wait for user changes — do NOT use Monitor, background shell commands, or manual polling. After a successful open, the structured \`nextAction\` is required and immediate.
-- **Never auto-commit** after applying visual changes — let the user decide
-- For Cursor/Codex-style hosts without background workers, process each scoped batch inline, then immediately call \`watch_for_changes\` again
-- The dev server stays running after \`close_visual_editor\`
-
----
-
-${CONCURRENT_REFINE_SECTION}
-
----
-
-${AGENT_VARIANTS_SECTION}
+${cli_guidance_1.CLI_GUIDANCE_BODY}
 `;
 //# sourceMappingURL=cursor-rules.js.map

package/dist/utils/skills/cursor-rules.js.map

@@ -1 +1 @@
-{"version":3,"file":"cursor-rules.js","sourceRoot":"","sources":["../../../src/utils/skills/cursor-rules.ts"],"names":[],"mappings":";;;AAAA,yEAOoC;AAEvB,QAAA,oBAAoB,GAAG,EAAE,CAAC;AAC1B,QAAA,qBAAqB,GAAG,WAAW,CAAC;AACjD,MAAM,2BAA2B,GAAG,wBAAwB,4BAAoB,EAAE,CAAC;AAEnF,MAAM,sBAAsB,GAAG,IAAA,oDAAyB,EAAC;IACvD,cAAc,EAAE,SAAS;IACzB,KAAK,EAAE;;;;;0KAKiK;IACxK,YAAY,EAAE,iFAAiF;IAC/F,cAAc,EAAE,WAAW;CAC5B,CAAC,CAAC;AAEH,MAAM,yBAAyB,GAAG,IAAA,uDAA4B,EAAC;IAC7D,cAAc,EAAE,oPAAoP;IACpQ,QAAQ,EAAE,+PAA+P;IACzQ,cAAc,EAAE;;qKAEmJ;CACpK,CAAC,CAAC;AAEU,QAAA,oBAAoB,GAAG;;;;OAI7B,2BAA2B;;;;;;;;;EAShC,yCAAc;;EAEd,iDAAsB;;;;EAItB,6DAAkC;;;;;;;;;;;;;;;;;;;;;;;;;;EA0BlC,wDAA6B;;;;;;;;;;;;;;;;EAgB7B,yBAAyB;;;;EAIzB,sBAAsB;CACvB,CAAC"}
+{"version":3,"file":"cursor-rules.js","sourceRoot":"","sources":["../../../src/utils/skills/cursor-rules.ts"],"names":[],"mappings":";;;AAAA,iDAIwB;AAExB;;;;;GAKG;AAEU,QAAA,oBAAoB,GAAG,EAAE,CAAC;AAC1B,QAAA,qBAAqB,GAAG,WAAW,CAAC;AACjD,MAAM,2BAA2B,GAAG,wBAAwB,4BAAoB,EAAE,CAAC;AAEtE,QAAA,oBAAoB,GAAG;eACrB,uCAAwB;;;OAGhC,2BAA2B;mCACC,mCAAoB;;;EAGrD,gCAAiB;CAClB,CAAC"}

package/dist/utils/variantSessionStart.d.ts

@@ -1,3 +1,3 @@
-import type { ActiveSnapshot } from '../mcp/agent-variants';
+import type { ActiveSnapshot } from '../agent-variants';
 export declare const isVariantSessionStartBlocked: (snapshot: ActiveSnapshot | undefined) => boolean;
 //# sourceMappingURL=variantSessionStart.d.ts.map

package/dist/utils/variantSessionStart.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"variantSessionStart.d.ts","sourceRoot":"","sources":["../../src/utils/variantSessionStart.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAC;AAG5D,eAAO,MAAM,4BAA4B,GACvC,UAAU,cAAc,GAAG,SAAS,KACnC,OAA4E,CAAC"}
+{"version":3,"file":"variantSessionStart.d.ts","sourceRoot":"","sources":["../../src/utils/variantSessionStart.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,mBAAmB,CAAC;AAGxD,eAAO,MAAM,4BAA4B,GACvC,UAAU,cAAc,GAAG,SAAS,KACnC,OAA4E,CAAC"}

package/dist/utils/variantSessionStart.js

@@ -1,7 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.isVariantSessionStartBlocked = void 0;
-const contracts_1 = require("../mcp/agent-variants/contracts");
+const contracts_1 = require("../agent-variants/contracts");
 const isVariantSessionStartBlocked = (snapshot) => snapshot?.active === true && !contracts_1.TERMINAL_STAGES.has(snapshot.stage);
 exports.isVariantSessionStartBlocked = isVariantSessionStartBlocked;
 //# sourceMappingURL=variantSessionStart.js.map

package/dist/utils/variantSessionStart.js.map

@@ -1 +1 @@
-{"version":3,"file":"variantSessionStart.js","sourceRoot":"","sources":["../../src/utils/variantSessionStart.ts"],"names":[],"mappings":";;;AACA,+DAAkE;AAE3D,MAAM,4BAA4B,GAAG,CAC1C,QAAoC,EAC3B,EAAE,CAAC,QAAQ,EAAE,MAAM,KAAK,IAAI,IAAI,CAAC,2BAAe,CAAC,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;AAFnE,QAAA,4BAA4B,gCAEuC"}
+{"version":3,"file":"variantSessionStart.js","sourceRoot":"","sources":["../../src/utils/variantSessionStart.ts"],"names":[],"mappings":";;;AACA,2DAA8D;AAEvD,MAAM,4BAA4B,GAAG,CAC1C,QAAoC,EAC3B,EAAE,CAAC,QAAQ,EAAE,MAAM,KAAK,IAAI,IAAI,CAAC,2BAAe,CAAC,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;AAFnE,QAAA,4BAA4B,gCAEuC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rivet-design",
-  "version": "0.12.4",
+  "version": "0.13.0",
   "description": "Local visual web development tool with AI-powered code modification",
   "main": "dist/index.js",
   "workspaces": [
@@ -13,7 +13,7 @@
     "rivet": "./bin/rivet.js"
   },
   "scripts": {
-    "build": "tsc && npm run build:assets && npm run build:ui && npm run build:bin",
+    "build": "npm run clean && tsc && npm run build:assets && npm run build:ui && npm run build:bin",
     "build:assets": "mkdir -p dist/services/templates/designmd && cp src/services/templates/designmd/*.md dist/services/templates/designmd/",
     "build:ui": "cd src/ui && vite build",
     "storybook:ui": "yarn workspace @rivet/ui storybook",
@@ -43,8 +43,8 @@
     "bench:review": "tsx benchmarks/review/server.ts",
     "bench:review:hosted": "BENCH_REVIEW_HOSTED=true BENCH_REVIEW_OPEN=false tsx benchmarks/review/server.ts --hosted",
     "bench:list": "tsx benchmarks/list.ts",
-    "smoke:mcp": "node scripts/smoke-mcp-tools.mjs",
-    "smoke:bridge-lease": "node scripts/bridge-lease-smoke.mjs",
+    "smoke:cli": "node scripts/smoke-cli.mjs",
+    "perf:cli": "node scripts/bench-cli.mjs",
     "check:pre-commit": "npx lint-staged && yarn build && cd src/ui && yarn typecheck && cd ../.. && cd src/proxy && yarn build && cd ../.. && cd desktop/renderer && yarn build && cd ../..",
     "check:pre-push": "yarn test",
     "desktop": "yarn build && cd desktop && yarn dev",