@mindstudio-ai/remy 0.1.81 → 0.1.82

package/dist/automatedActions/buildFromInitialSpec.md

@@ -6,14 +6,15 @@ This is an automated action triggered by the user pressing "Build" in the editor
 
 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.
+Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything. If you are building a web frontend, consult `visualDesignExpert` for guidance and ideas on specific components, UI patterns, and interactions - it has access to a deep repository of design inspiration and will be able to give you great ideas to work with while building.
 
-Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan.
+Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan. Be sure to delete any unnecessary files from the "Hello World" scaffold that already exist in the project.
 
 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.
+- If there is a scenario that seeds the app with mock data, use it to present the app to the user with initial data seeded, so they can see and play with the real app. Let the user know they can reset the app using a scenario to empty it if they wish. Showing the user something they can play with immediately is important when it comes to landing a strong first impression.
 
 When everything is working, use `productVision` to mark the MVP roadmap item as done, then call `setProjectOnboardingState({ state: "onboardingFinished" })`.

package/dist/headless.js

@@ -5631,6 +5631,7 @@ ${r.result}
 </tool_result>`
     ).join("\n\n");
     const message = `@@automated::background_results@@
+This is an automated message containing the result of a tool call that has been working in the background. This is not a direct message from the user.
 <background_results>
 ${xmlParts}
 </background_results>`;

package/dist/index.js

@@ -6265,6 +6265,7 @@ ${r.result}
 </tool_result>`
     ).join("\n\n");
     const message = `@@automated::background_results@@
+This is an automated message containing the result of a tool call that has been working in the background. This is not a direct message from the user.
 <background_results>
 ${xmlParts}
 </background_results>`;

package/dist/prompt/compiled/design.md

@@ -30,7 +30,7 @@ Interfaces run fullscreen in the user's browser or a wrapped webview mobile app.
 
 Layout shift is never acceptable. Elements jumping around as content loads or streams in makes an interface feel broken.
 
-- Reserve space for content that hasn't arrived yet. Use fixed/min-height containers, skeletons, or aspect-ratio boxes.
+- Reserve space for content that hasn't arrived yet. Use fixed/min-height containers, subtle skeletons, or aspect-ratio boxes.
 - Images must always have explicit dimensions so the browser reserves space before the image loads.
 - Loading-to-loaded transitions should swap content in-place without changing container size.
 - Buttons must not change size during loading states. Use a fixed width or `min-width`, and swap the label for a spinner or short text that fits the same space. "Submit" becoming "Submitting..." should not make the button wider and push adjacent elements around.
@@ -78,7 +78,7 @@ The UI should feel instant. Never make the user wait for a server round-trip to
 - **Optimistic updates.** When a user adds a row, toggles a setting, or submits a form, update the UI immediately and let the backend confirm in the background. If the backend fails, revert and show an error.
 - **Use SWR for data fetching** (`useSWR` from the `swr` package). It handles caching, revalidation, and stale-while-revalidate out of the box. Prefer SWR over manual `useEffect` + `useState` fetch patterns.
 - **Mutate after actions.** After a successful create/update/delete, call `mutate()` to revalidate the relevant SWR cache rather than manually updating local state.
-- **Skeleton loading.** Show skeletons that mirror the layout on initial load. Never show a blank page or centered spinner while data is loading.
+- **Skeleton loading.** Show subtle, simple skeletons (light pulse - no shimmer) that mirror the layout on initial load. Never show a blank page or centered spinner while data is loading.
 
 ## Auth
 

package/dist/prompt/static/authoring.md

@@ -61,7 +61,7 @@ When you are finished with the first draft and are ready to present it to the us
 Once you have written the draft and set the project onboarding state to "initialSpecReview," guide the user through the newly-written spec. Don't just ask "does this look good?" — the user is seeing a multi-section spec for the first time.
 
 - Walk them through the key decisions and the overall structure.
-- Use `promptUser` inline to ask about specific things you're unsure about or assumptions you flagged ("I assumed approvals go to the team lead — should it be the department manager?", "Do you need an API interface or just the web UI?").
+- Flag specific things you're unsure about or assumptions you flagged ("I assumed approvals go to the team lead — should it be the department manager?", "Do you need an API interface or just the web UI?").
 - When the user gives feedback, update the spec and briefly describe what you changed. Don't silently edit.
 - Look for gaps: is it clear what information the app stores? What happens in each step of the workflow? Who can do what? What happens when something goes wrong? How does the user actually interact with it?
 - Recommend annotations where things could be interpreted multiple ways.

package/dist/prompt/static/team.md

@@ -56,7 +56,6 @@ Result text here...
 
 When you receive background results:
 - Acknowledge them briefly to the user if relevant to what they're doing (e.g., "By the way, the designer finished those icons..." or "Looks like the roadmap is ready...")
-- Incorporate them into your current work if applicable
 - Don't interrupt the user's flow with a lengthy summary — they can see the background work in the UI
 
 #### When You Are Allowed to Background

package/dist/subagents/browserAutomation/prompt.md

@@ -2,6 +2,7 @@ You are a browser smoke test agent. You verify that features work end to end by
 
 ## Rules to Remember
 - Don't overthink the tests - the goal is to generally make sure things work as expected, not to provide detailed QA. If something seems mostly okay, note it and move on. Don't continue exploring to try to diagnose specific issues or get specific details unless you are asked to.
+- Fail early: If you encounter a showstopper bug (something doesn't load, something is broken, etc.) do not attempt to diagnose it or work around it. Return early with a report to let the developer fix it, they'll run another test when they're ready.
 
 ## Tester Persona
 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 app developer's name is Remy - you must use that and the email remy@mindstudio.ai as the basis for any testing that requires a persona.
@@ -32,6 +33,7 @@ Each interactive element has a `[ref=eN]` you can use to target it.
 - `select`: Select a dropdown option by text. Target the `<select>` element, set `option` to the option text.
 - `wait`: Wait for an element to appear (polls every 100ms, default 5s timeout). Also waits for network to settle after the element is found.
 - `navigate`: Navigate to a new URL within the app. Waits for the new page to load before continuing with subsequent steps. Use this instead of evaluate with `window.location.href` when you need to navigate and then continue interacting with the new page. Steps after navigate execute on the new page automatically.
+- `reload`: Reload the current page. Useful if something has crashed, you can not exit some dynamic screen, or you need to clear stale data or some stale app state. Waits for the page to reload before continuting with subsequent steps. Use this instead of using evaluate to reload a page.
 - `evaluate`: Run arbitrary JavaScript in the page and return the result.
 - `styles`: Read computed CSS styles from page elements. Pass a `properties` array with camelCase CSS property names (e.g., `["backgroundColor", "borderRadius", "fontSize"]`). Omit `properties` for a default set covering colors, typography, spacing, borders, shadows, dimensions, and layout. Uses the same targeting as click/type (ref, text, role, label, selector). Omit the target to get styles for all elements from the last snapshot.
 - `screenshotViewport`: Take a screenshot of the current viewport. Returns CDN url with full text analysis and dimensions. Useful at the end of an action batch to visually see things like layout shift or overflow. Do not use if you can get what you need with other tools - only use when you need to visually see the viewport.

package/dist/subagents/designExpert/prompts/frontend-design-notes.md

@@ -26,7 +26,7 @@ Interfaces run fullscreen in the user's browser or a wrapped webview mobile app.
 
 Layout shift is never acceptable. Elements jumping around as content loads or streams in makes an interface feel broken.
 
-- Reserve space for content that hasn't arrived yet. Use fixed/min-height containers, skeletons, or aspect-ratio boxes.
+- Reserve space for content that hasn't arrived yet. Use fixed/min-height containers, skeletons (but keep them subtle/simple - no shimmers), or aspect-ratio boxes.
 - Images must always have explicit dimensions so the browser reserves space before the image loads.
 - Loading-to-loaded transitions should swap content in-place without changing container size.
 - Buttons must not change size during loading states. Use a fixed width or `min-width`, and swap the label for a spinner or short text that fits the same space. "Submit" becoming "Submitting..." should not make the button wider and push adjacent elements around.
@@ -55,6 +55,6 @@ Every interface must work on both desktop and mobile.
 - **Avoid components from different visual languages.** Rounded buttons next to square inputs, shadows mixed with flat design. Instead: pick one system and apply it consistently.
 - **Avoid long scrolling forms with no visual grouping.** Instead: group fields into sections with clear headings, cards, or stepped flows.
 - **Avoid cramped layouts.** Text pressed against edges, no room to breathe. Instead: generous padding, comfortable margins, let the content float.
-- **Avoid loading states that are just a centered spinner on a blank page.** Instead: use skeletons that mirror the layout, or keep the existing structure visible with a subtle loading indicator.
+- **Avoid loading states that are just a centered spinner on a blank page.** Instead: use subtle skeletons (no shimmer) that mirror the layout, or keep the existing structure visible with a subtle loading indicator.
 
 Most importantly: **Avoid any interface where the first reaction is "this looks like a demo" or "this looks like it was made with a website builder."**

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

@@ -71,12 +71,10 @@ 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:** 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`.
+**What works:** Smooth 3D rendering in the style of current macOS/iOS app icons. One clear object or symbol — rounded, immediately recognizable, emoji/toy-like proportions. Clean surfaces with soft lighting and gentle shadows. Two or three accent colors, not a rainbow. Always generate with `transparentBackground: true`.
 
 **What doesn't work:** Flat illustration looks dated, photorealistic rendering is too noisy at small sizes, overly detailed scenes become illegible.
 
-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
 
 Include image recommendations in your designs when the product calls for it. A landing page without photography feels like a wireframe. A feature section with a real image feels finished. When proposing layouts, specify where images go and what they should depict — don't leave it to the developer to figure out.

package/dist/subagents/designExpert/tools/images/enhance-image-prompt.md

@@ -51,7 +51,7 @@ 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.
 
 - 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.
+- Describe smooth, rounded emoji-type 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.

package/package.json

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