"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 = 23;
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\`
   - Edits files in \`input.worktreePath\` (each variant has its own isolated worktree)
   - Calls \`report_variant_complete({ 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',
});
exports.CLAUDE_SKILL_CONTENT = `---
name: rivet
description: Rivet — two flows. Visual editor for point-and-click UI changes ("open rivet", "use rivet", "make a visual change"). Agent-variants for exploring N parallel design directions before committing ("create variants of X", "show me 3-5 options for X", "build me a settings page from scratch", "create a new Vite todo app", "scaffold a Next.js dashboard"). Pick the flow based on the user's request — see "Picking the flow" below.
---

${CLAUDE_SKILL_VERSION_MARKER}
# Rivet

Two flows: the **visual editor** (point-and-click changes to a web app — including an empty or HTML-only folder, which opens in static mode) and the **agent-variants flow** (explore N parallel design directions before committing).

${shared_variants_protocol_1.PICKING_THE_FLOW_TABLE}

## Visual Editor flow

## Starting a session

An **empty or HTML-only folder is a valid target** — \`detect_project\` returns \`framework: 'static'\` for it and \`open_visual_editor\` opens it in static mode (no dev server). When the user says "open rivet" / "use rivet here" in such a folder, open the editor — do NOT refuse or reroute to variants because there's "no app yet."

1. Call \`detect_project\` — returns project info including \`framework\` and \`projectPath\`
2. Call \`open_visual_editor({ projectPath, framework })\` — do NOT pass \`startPort\` or any port; the tool handles port selection automatically
3. Tell the user: "Rivet is ready — make your visual changes and click 'Send to Claude Code'."
4. Call \`watch_for_changes({ sessionId })\` to wait for the user's changes.

## Applying changes

When \`watch_for_changes\` returns (or the user asks manually):

1. Call \`get_pending_changes({ sessionId })\` to pick up queued changes
2. If \`hasChanges: false\`, tell the user no changes are pending yet
3. If \`hasChanges: true\`, apply the changes to the source files listed in \`sourceFiles\`
4. Call \`get_pending_changes({ sessionId, message: "summary of changes", refresh_git: true })\` so the Rivet UI updates
5. Hot reload happens automatically after file changes
6. Tell the user what you changed
7. **STOP and ask the user:** "Want me to keep watching for more Rivet changes, or go back to normal prompting?"
8. If they want to keep watching, go back to step 1 in the "Applying changes" section

## Ending a session

When the user says they're done, call \`close_visual_editor({ sessionId })\`.

## Rules

- **Always call \`detect_project\` first** — never assume the dev server is running
- **Always use \`watch_for_changes\`** to wait for user changes — do NOT use Monitor, background shell commands, or manual polling
- **Never auto-commit** after applying visual changes — let the user decide
- The dev server stays running after \`close_visual_editor\`

---

${AGENT_VARIANTS_SECTION}
`;
//# sourceMappingURL=claude-skill.js.map