@mindstudio-ai/remy 0.1.51 → 0.1.52

package/dist/headless.js

@@ -406,6 +406,8 @@ ${isLspConfigured() ? `<typescript_lsp>
 
 {{static/instructions.md}}
 
+<!-- cache_breakpoint -->
+
 <project_onboarding>
 New projects progress through four onboarding states. The user might skip this entirely and jump straight into working on the existing scaffold (which defaults to onboardingFinished), but ideally new projects move through each phase:
 
@@ -2768,6 +2770,8 @@ function getBrowserAutomationPrompt() {
     const appSpec = fs13.readFileSync("src/app.md", "utf-8").trim();
     return `${BASE_PROMPT}
 
+<!-- cache_breakpoint -->
+
 <app_context>
 ${appSpec}
 </app_context>`;
@@ -3570,6 +3574,7 @@ function getDesignExpertPrompt() {
     "{{font_library}}",
     getFontLibrarySample()
   ).replace("{{visual_design_references}}", getDesignReferencesSample()).replace("{{ui_case_studies}}", getUiInspirationSample());
+  prompt += "\n\n<!-- cache_breakpoint -->";
   if (specContext) {
     prompt += `
 
@@ -3873,6 +3878,7 @@ function getProductVisionPrompt() {
   const specContext = loadSpecContext();
   const roadmapContext = loadRoadmapContext();
   const parts = [BASE_PROMPT2, loadPlatformBrief()];
+  parts.push("<!-- cache_breakpoint -->");
   if (specContext) {
     parts.push(specContext);
   }
@@ -4050,6 +4056,7 @@ var codeSanityCheckTool = {
     }
     const specContext = loadSpecContext();
     const parts = [BASE_PROMPT3, loadPlatformBrief()];
+    parts.push("<!-- cache_breakpoint -->");
     if (specContext) {
       parts.push(specContext);
     }

package/dist/index.js

@@ -2770,6 +2770,8 @@ function getBrowserAutomationPrompt() {
     const appSpec = fs11.readFileSync("src/app.md", "utf-8").trim();
     return `${BASE_PROMPT}
 
+<!-- cache_breakpoint -->
+
 <app_context>
 ${appSpec}
 </app_context>`;
@@ -3685,6 +3687,7 @@ function getDesignExpertPrompt() {
     "{{font_library}}",
     getFontLibrarySample()
   ).replace("{{visual_design_references}}", getDesignReferencesSample()).replace("{{ui_case_studies}}", getUiInspirationSample());
+  prompt += "\n\n<!-- cache_breakpoint -->";
   if (specContext) {
     prompt += `
 
@@ -4031,6 +4034,7 @@ function getProductVisionPrompt() {
   const specContext = loadSpecContext();
   const roadmapContext = loadRoadmapContext();
   const parts = [BASE_PROMPT2, loadPlatformBrief()];
+  parts.push("<!-- cache_breakpoint -->");
   if (specContext) {
     parts.push(specContext);
   }
@@ -4243,6 +4247,7 @@ var init_codeSanityCheck = __esm({
         }
         const specContext = loadSpecContext();
         const parts = [BASE_PROMPT3, loadPlatformBrief()];
+        parts.push("<!-- cache_breakpoint -->");
         if (specContext) {
           parts.push(specContext);
         }
@@ -5371,6 +5376,8 @@ ${isLspConfigured() ? `<typescript_lsp>
 
 {{static/instructions.md}}
 
+<!-- cache_breakpoint -->
+
 <project_onboarding>
 New projects progress through four onboarding states. The user might skip this entirely and jump straight into working on the existing scaffold (which defaults to onboardingFinished), but ideally new projects move through each phase:
 

package/dist/prompt/static/authoring.md

@@ -19,7 +19,7 @@ The scaffold starts with these spec files that cover the full picture of the app
 - **`src/interfaces/@brand/voice.md`** — voice and terminology: tone, error messages, word choices
 - **`src/roadmap/`** — feature roadmap. One file per feature (`type: roadmap`). See "Roadmap" below.
 
-Start from these and extend as needed. Add interface specs for other interface types (`api.md`, `cron.md`, `agent.md`, etc.) if the app uses them. Split `app.md` into multiple files if the domain is complex. The agent uses the entire `src/` folder as compilation context, so organize however serves clarity.
+These are starting points, not constraints. Create as many spec files as the project needs — the `src/` folder is your workspace and every `.md` file in it becomes compilation context. If the app has substantial content (presentation slides, copy, lesson plans, menu items, quiz questions), put it in its own file (`src/content.md`, `src/slides.md`, `src/menu.md`, etc.) rather than cramming it into `app.md` or `web.md`. If the domain is complex, split `app.md` into multiple files by area (`src/billing.md`, `src/approvals.md`). Add interface specs for other interface types (`api.md`, `cron.md`, `agent.md`, etc.) if the app uses them. Organize however serves clarity — the platform reads the entire `src/` folder.
 
 Users often care about look and feel as much as (or more than) underlying data structures. Don't treat the brand and interface specs as an afterthought — for many users, the visual identity and voice are the first things they want to get right.
 

package/dist/prompt/static/team.md

@@ -16,6 +16,8 @@ The designer will return concrete resources: hex values, font names with CSS URL
 
 When delegating, describe the design problem — where the asset will be used, what it needs to communicate, what the brand feels like. Do not specify technical details like image formats, pixel dimensions, generation techniques, or workarounds. The design expert makes those decisions.
 
+Remember, the design agent starts from scratch each time - it has no history of previous messages you have sent it - so you need to make sure to provide all relevant context, including full context from its previous messages where it is relevant (e.g., "You proposed three different options [describe them in detail].... and the user has descided on XYZ...").
+
 Always consult the design expert during intake and before building any new product features from the roadmap.
 
 ### Product Vision (`productVision`)
@@ -38,7 +40,7 @@ Always consult the code sanity check before writing code in initialCodegen with
 
 ### QA (`runAutomatedBrowserTest`)
 
-For verifying complex stateful interactions: multi-step form submissions, auth flows, real-time updates, flows that require specific data/role setup. This spins up a full chrome browser automation — it's heavyweight. Do not use it for basic rendering or navigation checks. If you can verify something with a screenshot or by reading the code, do that instead. Run a scenario first to seed test data and set user roles. The user is able to watch QA work on their screen via a live browser preview - the cursor will move, type, etc - so you can also use this to demo functionality to the user and help them understand how to use their app.
+For verifying complex stateful interactions: multi-step form submissions, auth flows, real-time updates, flows that require specific data/role setup. This spins up a full chrome browser automation — it's heavyweight. Do not use it for basic rendering or navigation checks. If you can verify something with a screenshot or by reading the code, do that instead. Run a scenario first to seed test data and set user roles. The user is able to watch QA work on their screen via a live browser preview - the cursor will move, type, etc - so you can also use this to demo functionality to the user and help them understand how to use their app. Don't tell the QA agent what values it should use for testing, it will figure that out on its own.
 
 ### Background Execution
 

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

@@ -7,7 +7,7 @@ There are two categories of animation and you should think of them separately:
 - Design animations: think beautiful layout reveals, dramatic loading and success states for user onboarding, beautiful scroll-driven animations on a landing page. These are the place to show off - and if you're showing off you better get it right. Anything that looks dated or janky will be disappointing to the user. Done correctly, these animations are powerful and transformative - and when the design calls for it, you should take a risk and suggest something big, bold, and creative. Remember, the user can always modify or change things later. It's better to dream big and walk it back than to deliver something generic or bland.
 
 ### Patterns to Use
-- CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`) — native, off main thread, even though there is still a little lag in browser support we should always be using this when we need scroll-driven animations. Scroll driven animations that animate based on scrollport are very slick and look beautiful in landing pages. Think about how you can use them.
+- CSS scroll-driven animations (`animation-timeline: view()`) (aka "scrollytelling"). Scroll driven animations that animate based on scrollport are very slick and look beautiful in landing pages. Think about how you can use them.
 - Spring physics for natural-feeling motion
 - Purposeful micro-interactions — scaling, color shifts, depth changes on hover/click
 - Entrance reveals — content animating when it enters the view - can be powerful, but can very easily feel cheap if it is just sections of a page animating in on scroll, for example. Be very thoughtful and intentional when animating in this way.

package/package.json

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