@mindstudio-ai/remy 0.1.22 → 0.1.24

package/dist/headless.js

@@ -3126,7 +3126,7 @@ var productVisionTool = {
       properties: {
         task: {
           type: "string",
-          description: "What to do with the roadmap. Include relevant context. The tool reads spec and roadmap files automatically."
+          description: "Brief description of what happened or what is needed. Do not specify how many items to create, what topics to cover, or how to think. The agent reads the spec files and decides for itself."
         }
       },
       required: ["task"]

package/dist/index.js

@@ -3164,7 +3164,7 @@ var init_productVision = __esm({
           properties: {
             task: {
               type: "string",
-              description: "What to do with the roadmap. Include relevant context. The tool reads spec and roadmap files automatically."
+              description: "Brief description of what happened or what is needed. Do not specify how many items to create, what topics to cover, or how to think. The agent reads the spec files and decides for itself."
             }
           },
           required: ["task"]

package/dist/prompt/static/instructions.md

@@ -17,12 +17,13 @@
 ## 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 it looks like, what changed. Summarize in plain language rather than listing a per-file changelog.
+- **Milestones.** What you built, what it looks like, what changed. Summarize in plain language rather than listing a per-file changelog. When a sub-agent returns visual results (images, design direction), share them with the user inline before continuing your work — let them see what's been created while you keep going.
 - **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:
+- 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.
 - Use inline `code` formatting only for things the user needs to type or search for.

package/dist/static/instructions.md

@@ -17,12 +17,13 @@
 ## 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 it looks like, what changed. Summarize in plain language rather than listing a per-file changelog.
+- **Milestones.** What you built, what it looks like, what changed. Summarize in plain language rather than listing a per-file changelog. When a sub-agent returns visual results (images, design direction), share them with the user inline before continuing your work — let them see what's been created while you keep going.
 - **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:
+- 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.
 - Use inline `code` formatting only for things the user needs to type or search for.

package/dist/subagents/browserAutomation/prompt.md

@@ -1,6 +1,6 @@
 You are a browser smoke test agent. You verify that features work end to end by interacting with the live preview. Focus on outcomes: does the feature work? Did the expected content appear? Just do the thing and see if it worked.
 
-The user is watching the automation happen on their screen in real-time. When typing into forms or inputs, behave like a realistic user of this specific app. Use the app context (if provided) to understand the audience and tone. Type the way that audience would actually type — not formal, not robotic.
+The user is watching the automation happen on their screen in real-time. When typing into forms or inputs, behave like a realistic user of this specific app. Use the app context (if provided) to understand the audience and tone. Type the way that audience would actually type — not formal, not robotic. The coding agent's name is Remy, so use that and the email remy@mindstudio.ai for any testing that requires a name or email.
 
 ## Snapshot format
 

package/package.json

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