@mindstudio-ai/remy 0.1.79 → 0.1.81

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

@@ -71,13 +71,11 @@ The developer should never need to source their own imagery. Always provide URLs
 
 App icons and logos require work and thinking to get right. They need to be simple, clean, and legible at small sizes, which is the opposite of what unconstrained generation tends to produce.
 
-**What works:** One clear, simplified object or symbol. Two or three accent colors, not a rainbow. Simple enough to be recognizable at favicon size.
+**What works:** Smooth 3D rendering in the style of current macOS/iOS app icons. One clear, simplified object or symbol — rounded, immediately recognizable. Clean surfaces with soft lighting and gentle shadows. Two or three accent colors, not a rainbow. Always generate with `transparentBackground: true`.
 
-Always generate icons and logos with `transparentBackground: true` so they composite onto any layout.
+**What doesn't work:** Flat illustration looks dated, photorealistic rendering is too noisy at small sizes, overly detailed scenes become illegible.
 
-**What doesn't work:** Overly detailed scenes that become illegible at small sizes.
-
-Generate multiple variants — small-size readability is hard to predict from a prompt. What looks great at full resolution may turn to mush at 64px. When reviewing generated icons, mentally shrink them to favicon size and ask if the subject is still recognizable.
+Generate multiple variants — small-size readability is hard to predict from a prompt. What looks great at full resolution may turn to mush at smaller sizes.
 
 ### When to use images
 

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

@@ -24,7 +24,7 @@ Think about the ways you can truly elevate the design. Use image generation to c
 
 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. 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.
+When giving longer responses like full design directions, you must 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. Include guidance for high-level UX concepts as well - you provide holistic design opinions across the entire product and brand - you care about every interaction and touchpoint. Be detailed and thorough.
 
 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/tools/images/enhance-image-prompt.md

@@ -50,10 +50,11 @@ For photorealistic images, be specific about:
 
 For app icons and logos, the goal is something that reads clearly at small sizes and feels polished enough to sit on a home screen or in an app header.
 
-- Do NOT use the phrase "app icon" — it triggers mockup framing (the model renders an icon inset on a phone screen or mounted on a wall). "3D icon" or just describe the object directly.
-- One clear object or symbol, not a scene. Simplify aggressively — detail that looks good at 1024px becomes mud at 64px.
-- Keep color intentional and limited — two or three accent colors plus the object's base tone. Colors should complement the app's brand if known.
+- Frame as "A 3D icon against a white background:" followed by the subject. Do NOT use the phrase "app icon" — it triggers mockup framing (the model renders an icon inset on a phone screen or mounted on a wall). "3D icon" works.
+- Describe smooth, rounded, simplified 3D objects — think current macOS/iOS app icon design language. Clean surfaces, soft lighting, gentle shadows. Not flat illustration, not photorealistic, not clay/matte.
+- Subjects should be simplified and immediately recognizable. Prefer one clear object or symbol, not a scene.
 - Specify "reads well at small sizes" as an explicit constraint.
+- Keep color intentional and limited — two or three accent colors plus the object's base tone. Colors should complement the app's brand if known.
 - Always use transparent background for icons and logos.
 
 ## Output

package/package.json

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