@mindstudio-ai/remy 0.1.92 → 0.1.94

package/dist/headless.js

@@ -1688,7 +1688,7 @@ var setProjectMetadataTool = {
           type: "string",
           description: "Project display name. Keep it short (2-4 words). Use the app's actual name if the user mentioned one, otherwise pick something descriptive."
         },
-        shortDescription: {
+        description: {
           type: "string",
           description: "Short description for the project - user facing only - appears for the project creator in their list of apps."
         },
@@ -4026,7 +4026,7 @@ var PROMPT_TEMPLATE = readAsset(SUBAGENT, "prompt.md").replace(/\{\{([^}]+)\}\}/
   const k = key.trim();
   return RUNTIME_PLACEHOLDERS.has(k) ? match : readAsset(SUBAGENT, k);
 }).replace(/\n{3,}/g, "\n\n");
-function getDesignExpertPrompt() {
+function getDesignExpertPrompt(onboardingState) {
   const specContext = loadSpecContext();
   const indices = getSampleIndices(
     {
@@ -4055,6 +4055,14 @@ function getDesignExpertPrompt() {
     prompt += `
 
 ${specContext}`;
+  }
+  const state = onboardingState ?? "onboardingFinished";
+  if (state !== "onboardingFinished") {
+    prompt += `
+
+<project_phase>
+This project is in the "${state}" phase. The codebase is a placeholder scaffold or is being generated for the first time.
+</project_phase>`;
   }
   return prompt;
 }
@@ -4133,7 +4141,7 @@ var designExpertTool = {
     }
     const history = context.conversationMessages ? getSubAgentHistory(context.conversationMessages, "visualDesignExpert") : [];
     const result = await runSubAgent({
-      system: getDesignExpertPrompt(),
+      system: getDesignExpertPrompt(context.onboardingState),
       task: input.task,
       history: history.length > 0 ? history : void 0,
       tools: DESIGN_EXPERT_TOOLS,
@@ -5364,6 +5372,7 @@ async function runTurn(params) {
                 resolveExternalTool,
                 toolCallId: tc.id,
                 requestId,
+                onboardingState,
                 subAgentMessages,
                 conversationMessages: state.messages,
                 toolRegistry,

package/dist/index.js

@@ -1228,7 +1228,7 @@ var init_setProjectMetadata = __esm({
               type: "string",
               description: "Project display name. Keep it short (2-4 words). Use the app's actual name if the user mentioned one, otherwise pick something descriptive."
             },
-            shortDescription: {
+            description: {
               type: "string",
               description: "Short description for the project - user facing only - appears for the project creator in their list of apps."
             },
@@ -3927,7 +3927,7 @@ var init_getUiInspirationSample = __esm({
 });
 
 // src/subagents/designExpert/prompt.ts
-function getDesignExpertPrompt() {
+function getDesignExpertPrompt(onboardingState) {
   const specContext = loadSpecContext();
   const indices = getSampleIndices(
     {
@@ -3956,6 +3956,14 @@ function getDesignExpertPrompt() {
     prompt += `
 
 ${specContext}`;
+  }
+  const state = onboardingState ?? "onboardingFinished";
+  if (state !== "onboardingFinished") {
+    prompt += `
+
+<project_phase>
+This project is in the "${state}" phase. The codebase is a placeholder scaffold or is being generated for the first time.
+</project_phase>`;
   }
   return prompt;
 }
@@ -4069,7 +4077,7 @@ Visual design expert. Describe the situation and what you need \u2014 the agent
         }
         const history = context.conversationMessages ? getSubAgentHistory(context.conversationMessages, "visualDesignExpert") : [];
         const result = await runSubAgent({
-          system: getDesignExpertPrompt(),
+          system: getDesignExpertPrompt(context.onboardingState),
           task: input.task,
           history: history.length > 0 ? history : void 0,
           tools: DESIGN_EXPERT_TOOLS,
@@ -5403,6 +5411,7 @@ async function runTurn(params) {
                 resolveExternalTool,
                 toolCallId: tc.id,
                 requestId,
+                onboardingState,
                 subAgentMessages,
                 conversationMessages: state.messages,
                 toolRegistry,

package/dist/prompt/compiled/design.md

@@ -47,6 +47,9 @@ Every interface must work on both desktop and mobile. Think about how the app wi
 - Test at both extremes. A layout that only looks good at one breakpoint is not done.
 - When the app is primarily mobile (e.g., a mobile-first consumer app, a tool designed for on-the-go use), set `"defaultPreviewMode": "mobile"` in `web.json` so the editor previews in a mobile viewport by default.
 
+## Images
+The `designExpert` can create and source amazing, high quality images, graphics, illustrations, and logos to use in the interface - both with and without transparency. This is a huge level for upgrading the premium look, feel, and quality of the app. Use image logos directly instead of plain text wordmarks; use images for empty states, onboarding screens, full-screen loading, and more.
+
 ## Forms
 
 Forms should feel like interactions, not paperwork.
@@ -91,7 +94,7 @@ Authentication moments must feel natural and intuitive - they should not feel ja
 
 ### Rules for building auth screens
 
-Consult the `visualDesignExpert` to help you work through authentication at a high level. In general, a user should never land on auth at the root of an app (except in cases where the app is, e.g., an internal tool or some other protected experience). Users should be able to explore public resources, or at least encounter some kind of landing/introduction moment, before they get hit with a signup/login screen. Make auth feel like a natural moment in the user's journey.
+Consult the `visualDesignExpert` to help you work through authentication at a high level. For most apps, a user should never land on auth at the root of an app when opening it for the first time (except in cases where the app is, e.g., an internal tool or some other protected experience). Users should be able to explore public resources, or at least encounter some kind of landing/introduction moment, before they get hit with a signup/login screen. Make auth feel like a natural moment in the user's journey.
 
 **Auth modes:** Think about which mode(s) makes the most sense for the type of app you are building. Consumer apps likely to be used on mobile should probably tend toward SMS auth as the default - business apps used on desktop make more sense to use email verification - or allow both, there's no harm in giving the user choice!
 

package/dist/prompt/static/intake.md

@@ -1,6 +1,8 @@
 ## Intake Mode
 
-The user just arrived at a blank project with a full-screen chat. They may have a clear vision or nothing at all. Your job is to help them land on something exciting, specific, and buildable — then scope an MVP that gives them a real taste of it.
+The user just arrived at a blank project with a full-screen chat. They may have a clear vision or nothing at all. Your job is to help them land on something exciting, specific, and buildable — then scope an MVP that gives them a real taste of it. 
+
+The goal of the intake session is to truly and deeply align with the user on a shared vision for an MVP, not simply to collect requirements. This is a chance to help the user see the full potential of their idea and figure out what it is they *really* want, not just what they *say* they want. The effect of a good intake session is that the user is excited and can't wait to build their app - you have elevated their good ideas, quietly pruned their bad ones, and are ready to build something that will amaze them.
 
 ### What You're Working With
 
@@ -44,6 +46,7 @@ Your goal is to land on a specific, buildable idea — not to collect every requ
 - **If the user has a clear idea:** Acknowledge it briefly and move to a form. Don't over-discuss what's already clear.
 - **If the user is vague or exploring:** Ask what world they're in, what problem bugs them, what would be cool. Help them find a specific angle to build something compelling.
 - **If the user has no idea at all:** Ask what they're into — their work, hobbies, communities, side projects. People build the best apps around things they already care about. Start from who they are, not from what's technically possible.
+- **If the user arrives with a very detailed brief:** They've put real thought into this — acknowledge that. But treat the detail as signal about what they care about, not as a spec to implement literally. A detailed first message reveals priorities and intent: what excites them, what experience they're imagining, what they think matters most. Read through the specifics to understand those things, then bring your own expertise to the architecture. Ask a few questions to figure out which details are deeply held preferences and which are first-draft thinking they'd happily let you improve on. Then write a spec that delivers on their vision, drawing from their ideas where they're strong and making your own calls where your expertise adds value.
 
 Push past the generic first answer. When someone says "a todo app" or "a chatbot," that's a starting point, not a destination. What would make theirs *theirs*? Who's it for? What would make someone choose it over the obvious alternative? One good question can turn a forgettable idea into something they're genuinely excited to build.
 
@@ -52,7 +55,7 @@ But know when to stop exploring. Once there's a clear concept with a specific au
 ### Process
 
 1. **Brief chat** — Only when you need to understand the idea. If the user's first message gives you enough to work with, acknowledge it and move to a form. Always include a short text response before calling `promptUser` so the user has context for the form that appears.
-2. **Structured forms** — Use `promptUser` with `type: "form"` to collect details. If you can express your questions as structured options (select, text, color), use a form instead of asking in chat. Forms are easier for users than open-ended description, especially when they may not have the language for what they want. Use multiple forms if needed — one to clarify the core concept, another for data and workflows, another for design and brand. Each form should build on what you've already learned. Always use `type: "form"` during intake. 
+2. **Structured forms** — Use `promptUser` with `type: "form"` to collect details. If you can express your questions as structured options (select, text, etc), use a form instead of asking in chat. Forms are easier for users than open-ended description, especially when they may not have the language for what they want. Use multiple forms if needed — one to clarify the core concept, another for data and workflows, another for design and brand. Each form should build on what you've already learned. Always use `type: "form"` during intake.
 3. **Write the spec** — Turn everything into a first draft and get it on screen. The spec is a starting point, not a finished product. The user will refine it from there.
 
 ### What NOT to Do

package/package.json

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