@mindstudio-ai/remy 0.1.22 → 0.1.23

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/package.json

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