@mindstudio-ai/remy 0.1.48 → 0.1.49

package/dist/headless.js

@@ -7,45 +7,8 @@ var __export = (target, all) => {
 // src/headless.ts
 import { createInterface } from "readline";
 
-// src/assets.ts
-import fs from "fs";
-import path from "path";
-var ROOT = findRoot(
-  import.meta.dirname ?? path.dirname(new URL(import.meta.url).pathname)
-);
-function findRoot(start) {
-  let dir = start;
-  while (dir !== path.dirname(dir)) {
-    if (fs.existsSync(path.join(dir, "package.json"))) {
-      return dir;
-    }
-    dir = path.dirname(dir);
-  }
-  return start;
-}
-var ASSETS_BASE = fs.existsSync(path.join(ROOT, "dist", "prompt")) ? path.join(ROOT, "dist") : path.join(ROOT, "src");
-function assetPath(...segments) {
-  return path.join(ASSETS_BASE, ...segments);
-}
-function readAsset(...segments) {
-  const full = assetPath(...segments);
-  try {
-    return fs.readFileSync(full, "utf-8").trim();
-  } catch {
-    throw new Error(`Required asset missing: ${full}`);
-  }
-}
-function readJsonAsset(fallback, ...segments) {
-  const full = assetPath(...segments);
-  try {
-    return JSON.parse(fs.readFileSync(full, "utf-8"));
-  } catch {
-    return fallback;
-  }
-}
-
 // src/logger.ts
-import fs2 from "fs";
+import fs from "fs";
 var LEVELS = {
   error: 0,
   warn: 1,
@@ -94,11 +57,11 @@ function createLogger(module) {
 }
 
 // src/config.ts
-import fs3 from "fs";
-import path2 from "path";
+import fs2 from "fs";
+import path from "path";
 import os from "os";
 var log = createLogger("config");
-var CONFIG_PATH = path2.join(
+var CONFIG_PATH = path.join(
   os.homedir(),
   ".mindstudio-local-tunnel",
   "config.json"
@@ -106,7 +69,7 @@ var CONFIG_PATH = path2.join(
 var DEFAULT_BASE_URL = "https://api.mindstudio.ai";
 function loadConfigFile() {
   try {
-    const raw = fs3.readFileSync(CONFIG_PATH, "utf-8");
+    const raw = fs2.readFileSync(CONFIG_PATH, "utf-8");
     log.debug("Loaded config file", { path: CONFIG_PATH });
     return JSON.parse(raw);
   } catch (err) {
@@ -138,6 +101,43 @@ function resolveConfig(flags) {
   return { apiKey, baseUrl: baseUrl2 };
 }
 
+// src/assets.ts
+import fs3 from "fs";
+import path2 from "path";
+var ROOT = findRoot(
+  import.meta.dirname ?? path2.dirname(new URL(import.meta.url).pathname)
+);
+function findRoot(start) {
+  let dir = start;
+  while (dir !== path2.dirname(dir)) {
+    if (fs3.existsSync(path2.join(dir, "package.json"))) {
+      return dir;
+    }
+    dir = path2.dirname(dir);
+  }
+  return start;
+}
+var ASSETS_BASE = fs3.existsSync(path2.join(ROOT, "dist", "prompt")) ? path2.join(ROOT, "dist") : path2.join(ROOT, "src");
+function assetPath(...segments) {
+  return path2.join(ASSETS_BASE, ...segments);
+}
+function readAsset(...segments) {
+  const full = assetPath(...segments);
+  try {
+    return fs3.readFileSync(full, "utf-8").trim();
+  } catch {
+    throw new Error(`Required asset missing: ${full}`);
+  }
+}
+function readJsonAsset(fallback, ...segments) {
+  const full = assetPath(...segments);
+  try {
+    return JSON.parse(fs3.readFileSync(full, "utf-8"));
+  } catch {
+    return fallback;
+  }
+}
+
 // src/tools/_helpers/sidecar.ts
 var log2 = createLogger("sidecar");
 var baseUrl = null;
@@ -358,6 +358,10 @@ Current date/time: ${now}
   {{compiled/design.md}}
   </design>
 
+  <building_agent_interfaces>
+  {{compiled/agent-interfaces.md}}
+  </building_agent_interfaces>
+
   <media_cdn>
   {{compiled/media-cdn.md}}
   </media_cdn>
@@ -1099,7 +1103,7 @@ var presentPublishPlanTool = {
 var presentPlanTool = {
   definition: {
     name: "presentPlan",
-    description: "Present an implementation plan for user approval before making changes. Use this only for large, multi-step changes or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. If the user rejects with feedback, revise and present again.",
+    description: "Present an implementation plan for user approval before making changes. Use this only for large, multi-step changes like new features, new interface types, or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. If the user rejects with feedback, revise and present again.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1284,7 +1288,7 @@ var confirmDestructiveActionTool = {
       properties: {
         message: {
           type: "string",
-          description: "Explanation of what is about to happen and why confirmation is needed."
+          description: "Explanation of what is about to happen and why confirmation is needed in natural language - avoid technical terms or mentions of variables, bash commands, or other system-level concepts.."
         },
         confirmLabel: {
           type: "string",
@@ -2241,8 +2245,8 @@ function startStatusWatcher(config) {
     }
     inflight = true;
     try {
-      const ctx = getContext();
-      if (!ctx.assistantText && !ctx.lastToolName && !ctx.userMessage) {
+      const context = getContext();
+      if (!context) {
         return;
       }
       const res = await fetch(url, {
@@ -2251,13 +2255,7 @@ function startStatusWatcher(config) {
           "Content-Type": "application/json",
           Authorization: `Bearer ${apiConfig.apiKey}`
         },
-        body: JSON.stringify({
-          assistantText: ctx.assistantText.slice(-500),
-          lastToolName: ctx.lastToolName,
-          lastToolResult: ctx.lastToolResult?.slice(-200),
-          onboardingState: ctx.onboardingState,
-          userMessage: ctx.userMessage?.slice(-200)
-        }),
+        body: JSON.stringify({ context }),
         signal
       });
       if (!res.ok) {
@@ -2294,7 +2292,7 @@ function cleanMessagesForApi(messages) {
     if (msg.role === "user" && typeof msg.content === "string" && msg.content.startsWith("@@automated::")) {
       return {
         ...msg,
-        content: msg.content.replace(/^@@automated::[^@]*@@\n?/, "")
+        content: msg.content.replace(/^@@automated::[^@]*@@[^\n]*\n?/, "")
       };
     }
     if (!Array.isArray(msg.content)) {
@@ -2382,12 +2380,23 @@ ${partial}` : "[INTERRUPTED] Agent was interrupted before producing output.",
       let currentToolNames = "";
       const statusWatcher = startStatusWatcher({
         apiConfig,
-        getContext: () => ({
-          assistantText: getPartialText(contentBlocks),
-          lastToolName: currentToolNames || void 0,
-          lastToolResult: lastToolResult || void 0,
-          userMessage: task
-        }),
+        getContext: () => {
+          const parts = [];
+          if (task) {
+            parts.push(`Task: ${task.slice(-200)}`);
+          }
+          const text = getPartialText(contentBlocks);
+          if (text) {
+            parts.push(`Assistant text: ${text.slice(-500)}`);
+          }
+          if (currentToolNames) {
+            parts.push(`Tool: ${currentToolNames}`);
+          }
+          if (lastToolResult) {
+            parts.push(`Tool result: ${lastToolResult.slice(-200)}`);
+          }
+          return parts.join("\n");
+        },
         onStatus: (label) => emit2({ type: "status", message: label }),
         signal
       });
@@ -3413,6 +3422,7 @@ Each interface type invokes the same backend methods. Methods don't know which i
 - Telegram \u2014 message-handling bots
 - Email \u2014 inbound email processing
 - MCP \u2014 tool servers for AI assistants
+- Agent \u2014 conversational LLM interface with tool access to backend methods
 
 ## Backend
 
@@ -4476,6 +4486,7 @@ async function runTurn(params) {
     "editsFinished"
   ]);
   let lastCompletedTools = "";
+  let lastCompletedInput = "";
   let lastCompletedResult = "";
   while (true) {
     let getOrCreateAccumulator2 = function(id, name) {
@@ -4500,13 +4511,30 @@ async function runTurn(params) {
     let currentToolNames = "";
     const statusWatcher = startStatusWatcher({
       apiConfig,
-      getContext: () => ({
-        assistantText: subAgentText || getTextContent(contentBlocks).slice(-500),
-        lastToolName: currentToolNames || getToolCalls(contentBlocks).filter((tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)).at(-1)?.name || lastCompletedTools || void 0,
-        lastToolResult: lastCompletedResult || void 0,
-        onboardingState,
-        userMessage
-      }),
+      getContext: () => {
+        const parts = [];
+        if (userMessage) {
+          parts.push(`User message: ${userMessage.slice(-200)}`);
+        }
+        if (onboardingState) {
+          parts.push(`Build phase: ${onboardingState}`);
+        }
+        const text = subAgentText || getTextContent(contentBlocks).slice(-500);
+        if (text) {
+          parts.push(`Assistant text: ${text}`);
+        }
+        const toolName = currentToolNames || getToolCalls(contentBlocks).filter((tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)).at(-1)?.name || lastCompletedTools;
+        if (toolName) {
+          parts.push(`Tool: ${toolName}`);
+        }
+        if (lastCompletedInput) {
+          parts.push(`Tool input: ${lastCompletedInput.slice(-300)}`);
+        }
+        if (lastCompletedResult) {
+          parts.push(`Tool result: ${lastCompletedResult.slice(-200)}`);
+        }
+        return parts.join("\n");
+      },
       onStatus: (label) => onEvent({ type: "status", message: label }),
       signal
     });
@@ -4824,7 +4852,11 @@ async function runTurn(params) {
         }
       }
     }
-    lastCompletedTools = toolCalls.filter((tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)).map((tc) => tc.name).join(", ");
+    const lastNonExcluded = toolCalls.filter(
+      (tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)
+    );
+    lastCompletedTools = lastNonExcluded.map((tc) => tc.name).join(", ");
+    lastCompletedInput = JSON.stringify(lastNonExcluded.at(-1)?.input ?? {});
     lastCompletedResult = results.at(-1)?.result ?? "";
     for (const r of results) {
       state.messages.push({
@@ -4917,11 +4949,36 @@ ${partial}` : "[INTERRUPTED] Tool execution was stopped.";
   }
 };
 
+// src/automatedActions/resolve.ts
+var NON_ACTION_SENTINELS = /* @__PURE__ */ new Set(["background_results"]);
+function resolveAction(text) {
+  const match = text.match(/^@@automated::(\w+)@@(.*)/s);
+  if (!match) {
+    return null;
+  }
+  const triggerName = match[1];
+  if (NON_ACTION_SENTINELS.has(triggerName)) {
+    return null;
+  }
+  let params = {};
+  const remainder = match[2];
+  if (remainder) {
+    try {
+      params = JSON.parse(remainder.split("\n")[0]);
+    } catch {
+    }
+  }
+  let body = readAsset("automatedActions", `${triggerName}.md`);
+  body = body.replace(/^---[\s\S]*?---\s*/, "");
+  for (const [key, value] of Object.entries(params)) {
+    body = body.replaceAll(`{{${key}}}`, String(value));
+  }
+  return `@@automated::${triggerName}@@
+${body}`;
+}
+
 // src/headless.ts
 var log9 = createLogger("headless");
-function loadActionPrompt(name) {
-  return readAsset("prompt", "actions", `${name}.md`);
-}
 function emit(event, data, requestId) {
   const payload = { event, ...data };
   if (requestId) {
@@ -5223,15 +5280,11 @@ ${xmlParts}
       );
     }
     let userMessage = parsed.text ?? "";
-    const isCommand = !!parsed.runCommand;
-    const isHidden = isCommand || !!parsed.hidden;
-    if (parsed.runCommand === "sync") {
-      userMessage = loadActionPrompt("sync");
-    } else if (parsed.runCommand === "publish") {
-      userMessage = loadActionPrompt("publish");
-    } else if (parsed.runCommand === "buildFromInitialSpec") {
-      userMessage = loadActionPrompt("buildFromInitialSpec");
+    const resolved = resolveAction(userMessage);
+    if (resolved !== null) {
+      userMessage = resolved;
     }
+    const isHidden = resolved !== null || !!parsed.hidden;
     const onboardingState = parsed.onboardingState ?? "onboardingFinished";
     const system = buildSystemPrompt(
       onboardingState,

package/dist/index.js

@@ -826,7 +826,7 @@ var init_presentPlan = __esm({
     presentPlanTool = {
       definition: {
         name: "presentPlan",
-        description: "Present an implementation plan for user approval before making changes. Use this only for large, multi-step changes or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. If the user rejects with feedback, revise and present again.",
+        description: "Present an implementation plan for user approval before making changes. Use this only for large, multi-step changes like new features, new interface types, or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. If the user rejects with feedback, revise and present again.",
         inputSchema: {
           type: "object",
           properties: {
@@ -1029,7 +1029,7 @@ var init_confirmDestructiveAction = __esm({
           properties: {
             message: {
               type: "string",
-              description: "Explanation of what is about to happen and why confirmation is needed."
+              description: "Explanation of what is about to happen and why confirmation is needed in natural language - avoid technical terms or mentions of variables, bash commands, or other system-level concepts.."
             },
             confirmLabel: {
               type: "string",
@@ -2179,8 +2179,8 @@ function startStatusWatcher(config) {
     }
     inflight = true;
     try {
-      const ctx = getContext();
-      if (!ctx.assistantText && !ctx.lastToolName && !ctx.userMessage) {
+      const context = getContext();
+      if (!context) {
         return;
       }
       const res = await fetch(url, {
@@ -2189,13 +2189,7 @@ function startStatusWatcher(config) {
           "Content-Type": "application/json",
           Authorization: `Bearer ${apiConfig.apiKey}`
         },
-        body: JSON.stringify({
-          assistantText: ctx.assistantText.slice(-500),
-          lastToolName: ctx.lastToolName,
-          lastToolResult: ctx.lastToolResult?.slice(-200),
-          onboardingState: ctx.onboardingState,
-          userMessage: ctx.userMessage?.slice(-200)
-        }),
+        body: JSON.stringify({ context }),
         signal
       });
       if (!res.ok) {
@@ -2237,7 +2231,7 @@ function cleanMessagesForApi(messages) {
     if (msg.role === "user" && typeof msg.content === "string" && msg.content.startsWith("@@automated::")) {
       return {
         ...msg,
-        content: msg.content.replace(/^@@automated::[^@]*@@\n?/, "")
+        content: msg.content.replace(/^@@automated::[^@]*@@[^\n]*\n?/, "")
       };
     }
     if (!Array.isArray(msg.content)) {
@@ -2329,12 +2323,23 @@ ${partial}` : "[INTERRUPTED] Agent was interrupted before producing output.",
       let currentToolNames = "";
       const statusWatcher = startStatusWatcher({
         apiConfig,
-        getContext: () => ({
-          assistantText: getPartialText(contentBlocks),
-          lastToolName: currentToolNames || void 0,
-          lastToolResult: lastToolResult || void 0,
-          userMessage: task
-        }),
+        getContext: () => {
+          const parts = [];
+          if (task) {
+            parts.push(`Task: ${task.slice(-200)}`);
+          }
+          const text = getPartialText(contentBlocks);
+          if (text) {
+            parts.push(`Assistant text: ${text.slice(-500)}`);
+          }
+          if (currentToolNames) {
+            parts.push(`Tool: ${currentToolNames}`);
+          }
+          if (lastToolResult) {
+            parts.push(`Tool result: ${lastToolResult.slice(-200)}`);
+          }
+          return parts.join("\n");
+        },
         onStatus: (label) => emit2({ type: "status", message: label }),
         signal
       });
@@ -3515,6 +3520,7 @@ Each interface type invokes the same backend methods. Methods don't know which i
 - Telegram \u2014 message-handling bots
 - Email \u2014 inbound email processing
 - MCP \u2014 tool servers for AI assistants
+- Agent \u2014 conversational LLM interface with tool access to backend methods
 
 ## Backend
 
@@ -4718,6 +4724,7 @@ async function runTurn(params) {
     "editsFinished"
   ]);
   let lastCompletedTools = "";
+  let lastCompletedInput = "";
   let lastCompletedResult = "";
   while (true) {
     let getOrCreateAccumulator2 = function(id, name) {
@@ -4742,13 +4749,30 @@ async function runTurn(params) {
     let currentToolNames = "";
     const statusWatcher = startStatusWatcher({
       apiConfig,
-      getContext: () => ({
-        assistantText: subAgentText || getTextContent(contentBlocks).slice(-500),
-        lastToolName: currentToolNames || getToolCalls(contentBlocks).filter((tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)).at(-1)?.name || lastCompletedTools || void 0,
-        lastToolResult: lastCompletedResult || void 0,
-        onboardingState,
-        userMessage
-      }),
+      getContext: () => {
+        const parts = [];
+        if (userMessage) {
+          parts.push(`User message: ${userMessage.slice(-200)}`);
+        }
+        if (onboardingState) {
+          parts.push(`Build phase: ${onboardingState}`);
+        }
+        const text = subAgentText || getTextContent(contentBlocks).slice(-500);
+        if (text) {
+          parts.push(`Assistant text: ${text}`);
+        }
+        const toolName = currentToolNames || getToolCalls(contentBlocks).filter((tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)).at(-1)?.name || lastCompletedTools;
+        if (toolName) {
+          parts.push(`Tool: ${toolName}`);
+        }
+        if (lastCompletedInput) {
+          parts.push(`Tool input: ${lastCompletedInput.slice(-300)}`);
+        }
+        if (lastCompletedResult) {
+          parts.push(`Tool result: ${lastCompletedResult.slice(-200)}`);
+        }
+        return parts.join("\n");
+      },
       onStatus: (label) => onEvent({ type: "status", message: label }),
       signal
     });
@@ -5066,7 +5090,11 @@ async function runTurn(params) {
         }
       }
     }
-    lastCompletedTools = toolCalls.filter((tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)).map((tc) => tc.name).join(", ");
+    const lastNonExcluded = toolCalls.filter(
+      (tc) => !STATUS_EXCLUDED_TOOLS.has(tc.name)
+    );
+    lastCompletedTools = lastNonExcluded.map((tc) => tc.name).join(", ");
+    lastCompletedInput = JSON.stringify(lastNonExcluded.at(-1)?.input ?? {});
     lastCompletedResult = results.at(-1)?.result ?? "";
     for (const r of results) {
       state.messages.push({
@@ -5295,6 +5323,10 @@ Current date/time: ${now}
   {{compiled/design.md}}
   </design>
 
+  <building_agent_interfaces>
+  {{compiled/agent-interfaces.md}}
+  </building_agent_interfaces>
+
   <media_cdn>
   {{compiled/media-cdn.md}}
   </media_cdn>
@@ -5502,15 +5534,47 @@ ${partial}` : "[INTERRUPTED] Tool execution was stopped.";
   }
 });
 
+// src/automatedActions/resolve.ts
+function resolveAction(text) {
+  const match = text.match(/^@@automated::(\w+)@@(.*)/s);
+  if (!match) {
+    return null;
+  }
+  const triggerName = match[1];
+  if (NON_ACTION_SENTINELS.has(triggerName)) {
+    return null;
+  }
+  let params = {};
+  const remainder = match[2];
+  if (remainder) {
+    try {
+      params = JSON.parse(remainder.split("\n")[0]);
+    } catch {
+    }
+  }
+  let body = readAsset("automatedActions", `${triggerName}.md`);
+  body = body.replace(/^---[\s\S]*?---\s*/, "");
+  for (const [key, value] of Object.entries(params)) {
+    body = body.replaceAll(`{{${key}}}`, String(value));
+  }
+  return `@@automated::${triggerName}@@
+${body}`;
+}
+var NON_ACTION_SENTINELS;
+var init_resolve = __esm({
+  "src/automatedActions/resolve.ts"() {
+    "use strict";
+    init_assets();
+    NON_ACTION_SENTINELS = /* @__PURE__ */ new Set(["background_results"]);
+  }
+});
+
 // src/headless.ts
 var headless_exports = {};
 __export(headless_exports, {
   startHeadless: () => startHeadless
 });
 import { createInterface } from "readline";
-function loadActionPrompt(name) {
-  return readAsset("prompt", "actions", `${name}.md`);
-}
 function emit(event, data, requestId) {
   const payload = { event, ...data };
   if (requestId) {
@@ -5812,15 +5876,11 @@ ${xmlParts}
       );
     }
     let userMessage = parsed.text ?? "";
-    const isCommand = !!parsed.runCommand;
-    const isHidden = isCommand || !!parsed.hidden;
-    if (parsed.runCommand === "sync") {
-      userMessage = loadActionPrompt("sync");
-    } else if (parsed.runCommand === "publish") {
-      userMessage = loadActionPrompt("publish");
-    } else if (parsed.runCommand === "buildFromInitialSpec") {
-      userMessage = loadActionPrompt("buildFromInitialSpec");
+    const resolved = resolveAction(userMessage);
+    if (resolved !== null) {
+      userMessage = resolved;
     }
+    const isHidden = resolved !== null || !!parsed.hidden;
     const onboardingState = parsed.onboardingState ?? "onboardingFinished";
     const system = buildSystemPrompt(
       onboardingState,
@@ -5964,7 +6024,6 @@ var log9;
 var init_headless = __esm({
   "src/headless.ts"() {
     "use strict";
-    init_assets();
     init_logger();
     init_config();
     init_prompt4();
@@ -5972,6 +6031,7 @@ var init_headless = __esm({
     init_agent();
     init_session();
     init_toolRegistry();
+    init_resolve();
     log9 = createLogger("headless");
   }
 });

package/dist/prompt/compiled/agent-interfaces.md

@@ -0,0 +1,184 @@
+# Building Agent Interfaces
+
+Guidance for designing conversational AI agents and their frontends. An agent interface pairs an LLM (with per-user-scoped/authenticated access to app methods as tools, handled by platform automatically) with a chat UI. The developer authors the agent's character in MSFM (`src/interfaces/agent.md`); you compile it into a system prompt and tool descriptions (`dist/interfaces/agent/`).
+
+## Agent Design Principles
+
+### System prompts define character, not procedures
+
+A good system prompt establishes who the agent is — personality, tone, judgment style, the kind of person they sound like. It doesn't enumerate every possible interaction or restate what tools already describe.
+
+Short and opinionated beats long and comprehensive. "Sounds like a sharp, organized friend — brief by default" gives the model more to work with than a page of behavioral rules. Define constraints through character, not checklists. Let the model's judgment work.
+
+#### System Prompt Specifics
+Always include a note like "## Tool Usage
+- When multiple tool calls are independent, make them all in a single turn. Searching for three different products, or fetching two reference sites: batch them instead of doing one per turn." to help the model know it can run tools in parallel
+- The user's name and current role(s) at the time of message, if any, will be automatically appended to the end of every system prompt at runtime like:
+
+```
+## Current User
+Name: Jane Smith
+Roles: editor
+```
+- Unless the user specifies otherwise, always include a note that the agent can use markdown in responses (since the chat UI renders it) and should avoid using em dashes and emojis in its responses.
+
+### Tool descriptions are the most important artifact
+
+The system prompt says *who* the agent is. The tool descriptions say *what it can do*. A great tool description means the agent uses the tool correctly without explicit instruction. Do not be overly precise or micromanage. Your goal with tool descriptions is to provide context and faming- trust that the model is intelligent enough to fill in the gaps.. Each `tools/*.md` file should cover:
+
+- **When to use** this tool (and when NOT to — e.g. "NOT for marking complete, use toggle-todo")
+- **Parameter guidance** beyond the schema — what makes a good value, when to include optional fields, what to skip
+- **Return value** and how to present results to the user
+
+### Not every method should be a tool
+
+Expose methods that serve the conversational flow. Internal helpers, admin-only methods, and batch operations often don't belong in the agent's toolset. A focused set of well-described tools performs better than many underdocumented ones.
+
+Think about what the user would actually say in conversation. If a method only makes sense triggered by another system (cron, webhook) or through a form UI, it probably shouldn't be an agent tool.
+
+### The MSFM spec body drives compilation
+
+The spec (`src/interfaces/agent.md`) is the human-editable source. Write it for humans — voice, personality, capabilities, behavioral rules, edge cases. The body should read like a character brief, not a technical manual.
+
+Model ID and config belong in the frontmatter, not the prose. The prose focuses on judgment calls: "When a user adds a task, consider whether it would benefit from a note. For vague or complex tasks, attach guidance. For simple tasks, skip it."
+
+Use MSFM annotations for implementation-level notes that the compiler needs but the human reader doesn't — same pattern as app specs.
+
+When defining tools for multi-user apps with access restrictions, be sure to note the roles that are allowed or disallowed from accessing the tool, as well as any other restrictions. The actual tool invocation will be rejected at runtime if the requesting user is not allowed to access the underlying method, but defining this early allows the model to gate permissions cleanly rather than vomiting an error when the user tries to do something they're not permissioned for.
+
+### Anti-patterns
+
+- Avoid system prompts that restate tool schemas ("You have a tool called createTodo that takes a title and optional aiNotes...")
+- Avoid generic personalities ("You are a helpful assistant") — every agent should have a distinct voice, this is often the most fun part for the user building the agent - lean in and help them enjoy bringing their agent to life!
+- Avoid exposing all methods without considering conversational fit
+
+## Compiling the Agent Spec
+
+When building the `dist/interfaces/agent/`, consider the agent spec, as well as the larger context of the app and especially any `@brand/` guidelines. The agent should feel as though cut from the same cloth as the rest of the app - it is simply the same backend application projected into a different modality. Take care to make it consistent with the user's app, and then output:
+
+**`system.md`** — compiled from the spec body. Should feel like a character brief: who the agent is, how they talk, what they care about, key behavioral rules.
+
+**`tools/*.md`** — one file per exposed method. Rich markdown with when-to-use, examples, edge cases, return value guidance. These are what make the agent actually work well.
+
+**`agent.json`** — ties it together. Model config from frontmatter, paths to system prompt and tool files, optional `webInterfacePath`.
+
+## Chat UI Design
+
+When the agent has a web frontend (via `webInterfacePath`), the chat UI is a page within the web interface.
+
+### Frontend SDK: `createAgentChatClient()`
+
+The `@mindstudio-ai/interface` package provides `createAgentChatClient()` for thread management and streaming chat. All agent chat UIs should use this — don't build raw fetch/SSE handling.
+
+**Thread management:**
+
+```ts
+import { createAgentChatClient } from '@mindstudio-ai/interface';
+
+const chat = createAgentChatClient();
+
+const thread = await chat.createThread();
+const { threads, nextCursor } = await chat.listThreads();
+const full = await chat.getThread(thread.id);
+await chat.updateThread(thread.id, 'New title');
+await chat.deleteThread(thread.id);
+```
+
+**Sending messages (streaming):**
+
+`sendMessage` streams the agent's response via SSE. Use named callbacks for common events:
+
+```ts
+const response = chat.sendMessage(threadId, content, {
+  // Text deltas — append, don't replace
+  onText: (delta) => setText((prev) => prev + delta),
+
+  // Extended thinking (also deltas)
+  onThinking: (delta) => setThinking((prev) => prev + delta),
+  onThinkingComplete: (thinking, signature) => setThinking(''),
+
+  // Tool execution
+  onToolCallStart: (id, name) => { },
+  onToolCallResult: (id, output) => { },
+
+  // Errors
+  onError: (error) => console.error(error),
+});
+
+// Resolves when stream completes
+const { stopReason, usage } = await response;
+
+// Cancel mid-stream
+response.abort();
+```
+
+**Attachments:**
+
+Send images or documents alongside a message. Upload via `platform.uploadFile()` first, then pass CDN URLs as the 4th argument:
+
+```ts
+const url = await platform.uploadFile(file);
+
+chat.sendMessage(threadId, "What's in this document?", {
+  onText: (delta) => setText((prev) => prev + delta),
+}, {
+  attachments: [url],
+});
+```
+
+Images (`i.mscdn.ai`) are sent as vision input. Documents (`f.mscdn.ai`) have text extracted server-side and included in context. Attachments are preserved in thread history.
+
+**Key points:**
+- `onText` and `onThinking` receive deltas (append to state, don't replace)
+- `sendMessage` returns an `AbortablePromise` — a Promise with `.abort()`. Also accepts `signal` in callbacks for `AbortController` support
+- Tool call events (`onToolCallStart`, `onToolCallResult`) are available for showing progress indicators
+- Thread title is auto-generated after the first exchange
+
+### Layout
+
+Ask `visualDesignExpert` for ideas about how to design the chat UI in a way that is appropriate and unique to the app.
+
+User messages visually distinct from assistant messages (right-aligned, different background, or both). Keep it clean — no avatars unless they add meaning. Generous vertical spacing between messages so the conversation breathes. Use clean, beautiful animation where it is additive.
+
+### Streaming & Markdown
+
+Display tokens as they arrive. No loading spinners that block the whole view — show partial text immediately. A subtle cursor or animation at the streaming edge signals "still generating." The user should be reading, not waiting.
+
+Use `streamdown` for rendering markdown from streaming text. It handles unterminated blocks gracefully (the core problem with react-markdown during mid-stream rendering), includes Shiki syntax highlighting for code blocks, and supports KaTeX math and Mermaid diagrams. Install the base package and tree-shake plugins as needed (`@streamdown/code`, `@streamdown/math`, `@streamdown/mermaid`).
+
+Pay attention to streaming text animation — fast token delivery can look jarring, and slow delivery can look laggy. Throttling renders to ~50-100ms batches smooths things out.
+
+It is critical to never introduce layout shift or jarring transitions when dealing with responses. Messages should cleanly and smoothly transition between thinking, streaming, and completed states. Tool use should fit beautifully within the conversation and should never cause abrupt layout shift.
+
+### Scrolling
+
+Use `use-stick-to-bottom` (`github.com/stackblitz-labs/use-stick-to-bottom`) for auto-scroll behavior. It handles the standard chat scroll contract: stick to bottom as new content streams in, but stop following if the user scrolls up. Don't hand-roll this — the edge cases (momentum scrolling, resize, streaming while scrolled up) are fiddly.
+
+### Optimistic messages
+
+When the user sends a message, add it to the conversation immediately — don't wait for the server to acknowledge. Show a thinking/typing indicator in the assistant's response area right away so the UI feels instant. The indicator should appear the moment the user hits send, not when the first token arrives.
+
+### Tool calls
+
+Show tool activity in the chat as a compact, inline status that appears when `onToolCallStart` fires and resolves when `onToolCallResult` arrives. Never show raw JSON, tool IDs, or internal details — just a human-readable description of what's happening.
+
+### Input area
+
+Fixed at the bottom. Auto-growing textarea using `react-textarea-autosize`, not a single-line input. Clear send affordance (button or Enter). Disabled while the agent is streaming, with a visible stop/cancel button. Placeholder text that reflects the agent's personality, not generic "Type a message..."
+
+### Empty state
+
+The first screen should invite conversation. A greeting from the agent, a few suggested prompts, or a concise description of what the agent can help with can go a long way. Always make sure they are optional though - the user needs to be able to chat directly if they want. Match the agent's voice — a casual todo assistant and a formal legal review agent should feel completely different from the first screen.
+
+### Mobile
+
+Chat is inherently mobile-friendly — lean into it. Pay attention to viewport sizing on mobile as the virtual keyboard changes the available height. 
+
+### Respect the brand
+
+The chat UI uses the app's design system — colors, typography, voice from `@brand/`. Apply the same design standards as any other page in the web interface.
+
+### Anti-patterns
+
+- Avoid designs that look like dated messaging apps from 2015
+- Avoid robotic empty states ("Hello! I'm your AI assistant. How can I help you today?")

package/dist/prompt/compiled/interfaces.md

@@ -76,6 +76,8 @@ auth.name;
 auth.email;
 ```
 
+For apps with an agent interface, the SDK also provides `createAgentChatClient()` for thread management and streaming chat. See the "Building Agent Interfaces" section for usage details.
+
 The project uses `"jsx": "react-jsx"` (automatic JSX transform) — do not `import React from 'react'`. Only import the specific hooks and types you need (e.g., `import { useState, useEffect } from 'react'`).
 
 On deploy, the platform runs `npm install && npm run build` in the web directory and hosts the output on CDN.
@@ -230,6 +232,74 @@ Expose methods as AI tools.
 
 Each listed method becomes an MCP tool. Method names and descriptions from the manifest are used as tool names and descriptions.
 
+## Agent (Conversational Interface)
+
+A conversational interface where an LLM has access to the app's methods as tools. Unlike MCP (which exposes methods for external agents), the agent interface IS the agent — it has its own personality, system prompt, and model config, and orchestrates tool calls against the app's methods internally.
+
+### Spec: `src/interfaces/agent.md`
+
+The human-readable spec. Frontmatter contains structured fields; the prose body is the behavioral spec — voice, personality, capabilities, rules — written in MSFM.
+
+```yaml
+---
+name: Todo Assistant
+model: {"model": "claude-4-5-haiku", "temperature": 0.5, "maxResponseTokens": 15000}
+description: Conversational agent that helps users manage their to-do list.
+---
+```
+
+Frontmatter fields:
+- `name` — agent display name
+- `model` — JSON string with `model` (MindStudio model ID), `temperature`, `maxResponseTokens`, and optional `config` (model-specific settings like `reasoning`, `tools`, etc.). Use `askMindStudioSdk` to look up available model IDs and their config options when setting the model ID. The user's UI will have a nice visual picker to allow them to change it later, so only validate model when you're setting - otherwise assume this value to be correct if it changes.
+- `description` — one-liner for agent card/listing
+
+The prose body contains sections like Voice & Personality, Capabilities, Behavior — whatever structure serves the agent's character. This is compiled into the system prompt and tool descriptions.
+
+### Compiled Output: `dist/interfaces/agent/`
+
+```
+dist/interfaces/agent/
+├── agent.json          ← config the platform reads
+├── system.md           ← compiled system prompt
+└── tools/
+    ├── createTodo.md   ← rich tool description per method
+    ├── listTodos.md
+    └── ...
+```
+
+### Config (`agent.json`)
+
+```json
+{
+  "agent": {
+    "model": "claude-4-5-haiku",
+    "temperature": 0.5,
+    "maxTokens": 15000,
+    "systemPrompt": "system.md",
+    "tools": [
+      { "method": "create-todo", "description": "tools/createTodo.md" },
+      { "method": "list-todos", "description": "tools/listTodos.md" }
+    ],
+    "webInterfacePath": "/chat"
+  }
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `model` | MindStudio model ID (e.g. `claude-4-5-haiku`, `claude-4-6-sonnet`) |
+| `temperature` | Model temperature |
+| `maxTokens` | Max response tokens |
+| `systemPrompt` | Relative path to the compiled system prompt markdown file |
+| `tools` | Array of tool entries — `method` references a method `id` from the manifest, `description` is a relative path to a markdown file with rich tool docs (when to use, examples, edge cases, parameter guidance) |
+| `webInterfacePath` | Optional. If the app has a web interface with a chat page, this path tells the IDE where to show the preview. Otherwise the agent is accessed via API. |
+
+### Manifest Declaration
+
+```json
+{ "type": "agent", "path": "dist/interfaces/agent/agent.json" }
+```
+
 ## Manifest Declaration
 
 Each interface is declared in `mindstudio.json`:
@@ -244,7 +314,8 @@ Each interface is declared in `mindstudio.json`:
     { "type": "telegram", "path": "dist/interfaces/telegram/interface.json" },
     { "type": "webhook", "path": "dist/interfaces/webhook/interface.json" },
     { "type": "email", "path": "dist/interfaces/email/interface.json" },
-    { "type": "mcp", "path": "dist/interfaces/mcp/interface.json" }
+    { "type": "mcp", "path": "dist/interfaces/mcp/interface.json" },
+    { "type": "agent", "path": "dist/interfaces/agent/agent.json" }
   ]
 }
 ```

package/dist/prompt/compiled/manifest.md

@@ -89,7 +89,7 @@
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
-| `type` | `string` | Yes | One of: `web`, `api`, `discord`, `telegram`, `cron`, `webhook`, `email`, `mcp` |
+| `type` | `string` | Yes | One of: `web`, `api`, `discord`, `telegram`, `cron`, `webhook`, `email`, `mcp`, `agent` |
 | `path` | `string` | No | Path to the interface config file |
 | `config` | `object` | No | Inline config (alternative to a file) |
 | `enabled` | `boolean` | No | Default `true`. Set `false` to skip during build. |

package/dist/prompt/compiled/platform.md

@@ -22,6 +22,7 @@ my-app/
         assets/                          logos, icons
       web.md                           web UI spec
       api.md                           API conventions
+      agent.md                         agent personality and behavior spec
       cron.md                          scheduled job descriptions
     roadmap/                           feature roadmap (one file per item, type: roadmap)
 
@@ -46,6 +47,10 @@ my-app/
       webhook/interface.json             webhook config
       email/interface.json               email config
       mcp/interface.json                 MCP config
+      agent/                             agent interface
+        agent.json                         agent config
+        system.md                          compiled system prompt
+        tools/                             tool descriptions (one .md per method)
 ```
 
 ## What Goes Where

package/dist/prompt/static/authoring.md

@@ -19,7 +19,7 @@ The scaffold starts with these spec files that cover the full picture of the app
 - **`src/interfaces/@brand/voice.md`** — voice and terminology: tone, error messages, word choices
 - **`src/roadmap/`** — feature roadmap. One file per feature (`type: roadmap`). See "Roadmap" below.
 
-Start from these and extend as needed. Add interface specs for other interface types (`api.md`, `cron.md`, etc.) if the app uses them. Split `app.md` into multiple files if the domain is complex. The agent uses the entire `src/` folder as compilation context, so organize however serves clarity.
+Start from these and extend as needed. Add interface specs for other interface types (`api.md`, `cron.md`, `agent.md`, etc.) if the app uses them. Split `app.md` into multiple files if the domain is complex. The agent uses the entire `src/` folder as compilation context, so organize however serves clarity.
 
 Users often care about look and feel as much as (or more than) underlying data structures. Don't treat the brand and interface specs as an afterthought — for many users, the visual identity and voice are the first things they want to get right.
 

package/dist/prompt/static/instructions.md

@@ -18,12 +18,15 @@
 ## Communication
 The user can already see your tool calls, so most of your work is visible without narration. Focus text output on three things:
 - **Decisions that need input.** Questions, tradeoffs, ambiguity that blocks progress.
-- **Milestones.** What you built, what changed. Summarize in plain language rather than listing a per-file changelog.
+- **Milestones.** What you built, what changed. Summarize in plain language rather than listing a per-file changelog. If you've just built something, help the user understand how to use it, especially if they're seeing an MVP or new feature for the first time. For complex things, offer to walk them through a demo using `runAutomatedBrowserTest`
 - **Errors or blockers.** Something failed or the approach needs to shift.
 
 Skip the rest: narrating what you're about to do, restating what the user asked, explaining tool calls they can already see.
 
-Style:
+### Automated messages
+You will occasionally receive automated messages prefixed with `@@automated_message@@` - these are triggered by things like background agents returning their work, or by the user clicking a button in the UI (e.g., the user might click a "Build Feature" button in the product roadmap UI, and you will receive a message detailing what they want to build). You will be able to see these messages in your chat history but the user will not see them, so acknowledge them appropriately and then perform the requested work.
+
+## Style
 - Your messages are rendered as markdown. Use formatting (headers, bold, lists, code blocks) when it helps readability. You can also include images using `![alt](url)` — use this to show the user screenshots, generated images, or other visual references inline in your messages.
 - Keep language accessible. Describe what the app *does*, not how it's implemented, unless the user demonstrates technical fluency.
 - Always use full paths relative to the project root when mentioning files (`dist/interfaces/web/src/App.tsx`, not `App.tsx`). Paths will be rendered as clickable links for the user.

package/dist/prompt/static/intake.md

@@ -6,9 +6,10 @@ The user just arrived at a blank project with a full-screen chat. They may have
 Don't list features. Frame what MindStudio does through the lens of what the user wants. A MindStudio app is a managed TypeScript project with a backend, optional database, optional auth, and one or more interfaces. The key is that it's extremely flexible — here are some examples of what people build:
 
 - **Business tools** — dashboards, admin panels, approval workflows, data entry apps, internal tools with role-based access
-- **AI-powered apps** — chatbots, content generators, document processors, image/video tools, AI agents that take actions (send emails, update CRMs, post to Slack)
+- **AI-powered apps** — chatbots, content generators, document processors, image/video tools, conversational agents with tool access, AI agents that take actions (send emails, update CRMs, post to Slack)
 - **Automations with no UI** — a set of cron jobs that scrape websites and send alerts, a webhook handler that syncs data between services, an email processor that triages inbound support requests
-- **Bots** — Discord slash-command bots, Telegram bots, MCP tool servers for AI assistants
+- **Conversational AI Agents** - Full conversational AI agents with custom frontends and access to the app's methods as tools. Make all or only a subset of app functionality available - manage access to methods on a per-user basis; fully custom chat UIs, use any model you want, including Gemini, GPT, Anthropic Claude, and any of the hundreds of other models MindStudio supports automatically.
+- **Bots & agent tools** — Discord slash-command bots, Telegram bots, MCP tool servers
 - **Creative/interactive projects** — games with Three.js or p5.js, interactive visualizations, generative art, portfolio sites with dynamic backends
 - **API services** — backend logic exposed as REST endpoints for other systems to consume
 - **Simple static sites** — no backend needed, just a web interface with a build step

package/dist/prompt/static/team.md

@@ -38,7 +38,7 @@ Always consult the code sanity check before writing code in initialCodegen with
 
 ### QA (`runAutomatedBrowserTest`)
 
-For verifying complex stateful interactions: multi-step form submissions, auth flows, real-time updates, flows that require specific data/role setup. This spins up a full chrome browser automation — it's heavyweight. Do not use it for basic rendering or navigation checks. If you can verify something with a screenshot or by reading the code, do that instead. Run a scenario first to seed test data and set user roles.
+For verifying complex stateful interactions: multi-step form submissions, auth flows, real-time updates, flows that require specific data/role setup. This spins up a full chrome browser automation — it's heavyweight. Do not use it for basic rendering or navigation checks. If you can verify something with a screenshot or by reading the code, do that instead. Run a scenario first to seed test data and set user roles. The user is able to watch QA work on their screen via a live browser preview - the cursor will move, type, etc - so you can also use this to demo functionality to the user and help them understand how to use their app.
 
 ### Background Execution
 
@@ -60,7 +60,7 @@ When you receive background results:
 #### When You Are Allowed to Background
 
 You can only background the following two tasks, unless the user specifically asks you to do work in the background:
-- `productVision` seeding the intiial roadmap after writing the spec for the first time. This task takes a while and we can allow the user to continue building while it happens in the background
+- `productVision` seeding the intiial roadmap after writing the spec for the first time. This task takes a while and we can allow the user to continue building while it happens in the background.
 - After writing the spec, once you have finalized the shape of the app, ask `visualDesignExpert` to create an "iphone app store" style icon for the app, then set it with `setProjectMetadata({ iconUrl: ... })`
 
 Do not background any other tasks.

package/dist/subagents/codeSanityCheck/prompt.md

@@ -23,6 +23,8 @@ These are things we already know about and have decided to accept:
   - framer-motion
   - styled-components
   - @tabler/icons-react
+  - streamdown
+  - react-textarea-autosize
 - Preferences:
   - use [wouter](https://github.com/molefrog/wouter) for React routing instead of reaching for react-router
 

package/dist/subagents/designExpert/prompts/animation.md

@@ -7,7 +7,7 @@ There are two categories of animation and you should think of them separately:
 - Design animations: think beautiful layout reveals, dramatic loading and success states for user onboarding, beautiful scroll-driven animations on a landing page. These are the place to show off - and if you're showing off you better get it right. Anything that looks dated or janky will be disappointing to the user. Done correctly, these animations are powerful and transformative - and when the design calls for it, you should take a risk and suggest something big, bold, and creative. Remember, the user can always modify or change things later. It's better to dream big and walk it back than to deliver something generic or bland.
 
 ### Patterns to Use
-- CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`) — native, off main thread, even though there is still a little lag in browser support we should always be using this when we need scroll-driven animations.
+- CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`) — native, off main thread, even though there is still a little lag in browser support we should always be using this when we need scroll-driven animations. Scroll driven animations that animate based on scrollport are very slick and look beautiful in landing pages. Think about how you can use them.
 - Spring physics for natural-feeling motion
 - Purposeful micro-interactions — scaling, color shifts, depth changes on hover/click
 - Entrance reveals — content animating when it enters the view - can be powerful, but can very easily feel cheap if it is just sections of a page animating in on scroll, for example. Be very thoughtful and intentional when animating in this way.

package/dist/subagents/designExpert/prompts/instructions.md

@@ -20,7 +20,7 @@ Then, think about the layout and UI patterns - these are the core of the user's
 
 Every recommendation must be immediately usable in production. Font names with CSS URLs. Color palettes as hex values. Image URLs that resolve. No placeholders, no "you could try..." The developer interprets your results, so focus on being useful rather than rigidly formatted.
 
-When giving longer responses like full design plans, be sure to include implementation notes specific to this project for things the developer should pay extra close attention to as it builds to avoid any gotchas or oversights. The developer has a lot on their plate and we have a chance to help them out. Reference <app_interface_design_notes> as a resource for this information.
+When giving longer responses like full design plans, be sure to include implementation notes specific to this project for things the developer should pay extra close attention to as it builds to avoid any gotchas or oversights. The developer has a lot on their plate and we have a chance to help them out. Reference <app_interface_design_notes> as a resource for this information. The developer doesn't have access to your internal notes and references, so be explicit when referring to things, don't just say "Reference 11" or something like that, as they'll have no idea what that means.
 
 Important: Assume the developer has a terrible sense of design. Therefore, you must be direct and unambiguous, and be prescriptive about design choices - don't leave room for assumption or interpretation. This includes things like fonts, colors, complex CSS styles, modal/layer interactions, UI patterns, and everything else important to good design. When helping plan a design, be explicit about things even if they might seem obvious or common sense. The developer is highly technical and that is the best language in which to communicate precisely with them - use raw CSS snippets, pseudocode, and other technical terms liberally to be as precise and refined as possible - they will appreciate it and do better work as a result!
 

package/dist/subagents/designExpert/prompts/ui-patterns.md

@@ -6,7 +6,12 @@ Study the patterns provided in <ui_case_studies> and actually spend time breakin
 
 When descirbing UI patterns to the developer, be verbose and explicit. Describe every aspect - don't leave room for interpretation by the developer because it ain't gonna be pretty.
 
-
 ### Dated Patterns to Avoid
 
 The design should look like it could be an Apple iOS/macOS app of the year winner for 2026. Avoid long pages, things that feel like blogs, things that borrow from "dated" app store apps, and the like. It should feel like an award winner from the past two years, not an award winner from a decade ago.
+
+### Notes for Designing AI Chat Interfaces
+
+If the app includes an AI chat interface, take care to make it beautiful and intentional. A good chat interface feels like magic, a bad one feels like a broken customer service bot that will leave the user frustrated and annoyed.
+
+Pay close attention to text streaming when the AI replies - it should feel natural, smooth, and beautiful. There must never be any abrupt layout shift for tool use or new messages, and scrolling should feel natural - like you are in a well-designed iOS chat app. Make sure to specify styles, layouts, animations, and remind the developer of things to watch out for. Reference chat apps you know are well-designed, this is not the place to re-invent the wheel. Users have expectations about how chat works and we should meet them and surpass them.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.48",
+  "version": "0.1.49",
   "description": "MindStudio coding agent",
   "repository": {
     "type": "git",

package/dist/prompt/actions/buildFromInitialSpec.md

@@ -1,15 +0,0 @@
-This is an automated action triggered by the user pressing "Build" in the editor after reviewing the spec.
-
-The user has reviewed the spec and is ready to build. 
-
-Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything.
-
-Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan.
-
-When code generation is complete, verify your work: 
-- First, run use `runScenario` to seed test data, then use `runMethod` to confirm a method works 
-- If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
-- Ask the `visualDesignExpert` to take a screenshot and verity that the visual design looks correct. Fix any issues it flags - we want the user's first time seeing the finished product to truly wow them.
-- Finally, use `runAutomatedBrowserTest` to smoke-test the main UI flow. The dev database is a disposable snapshot, so don't worry about being destructive. Fix any errors before finishing.
-
-When everything is working, use `productVision` to mark the MVP roadmap item as done, then call `setProjectOnboardingState({ state: "onboardingFinished" })`.

package/dist/prompt/actions/publish.md

@@ -1,12 +0,0 @@
-This is an automated action triggered by the user pressing "Publish" in the editor.
-
-The user wants to deploy their app. Pushing to the `main` branch triggers a production deploy.
-
-Review the current state of the working tree — what has changed since the last commit, what's been committed since the last push, and the overall shape of recent work. Write a user-friendly changelog with `presentPublishPlan` — summarize what changed in plain language ("added vendor approval workflow", "fixed invoice totals", "updated the dashboard layout"). Reference specific code or file paths only when it helps clarity. This is what the user will see before deploying.
-
-If approved:
-- Stage and commit any uncommitted changes with a clean, descriptive commit message
-- Push to main
-- Let the user know their app is deploying
-
-If dismissed, acknowledge and do nothing.

package/dist/prompt/actions/sync.md

@@ -1,19 +0,0 @@
-This is an automated action triggered by the user pressing "Sync" in the editor.
-
-The user has manually edited files since the last sync. The `refs/sync-point` git ref marks the last known-good sync state. It's created using a temporary git index that captures the full working tree (including unstaged changes) as a tree object — so it represents exactly what the files looked like at sync time, not just what was committed.
-
-To see what the user changed, run: `git diff refs/sync-point -- src/ dist/`
-
-This compares the sync-point tree against the current working tree. Do not add `HEAD` or any other ref — the command as written diffs directly against the working tree, which is what you want.
-
-In the diff output: lines prefixed with `-` are what was in the file at last sync. Lines prefixed with `+` are the user's current edits. Sync should bring the other side in line with the `+` side.
-
-Analyze the changes and write a sync plan with `presentSyncPlan` — a clear markdown summary of what changed and what you intend to update. Write it for a human: describe changes in plain language ("renamed the greeting field", "added a note about error handling"), not as a list of file paths and code diffs. Reference specific code or file paths only when it helps clarity. The user will review and approve before you make changes.
-
-If approved:
-- If spec files (`src/`) changed, update the corresponding code in `dist/` to match
-- If code files (`dist/`) changed, update the corresponding spec in `src/` to match
-- If both changed, reconcile — spec is the source of truth for intent, but respect code changes that add implementation detail
-- When all files are synced, call `clearSyncStatus`
-
-If dismissed, acknowledge and do nothing.