@mindstudio-ai/remy 0.1.97 → 0.1.99

package/dist/headless.js

@@ -3566,7 +3566,7 @@ ${brief}
 }
 
 // src/subagents/designExpert/tools/images/imageGenerator.ts
-var ANALYZE_PROMPT = "You are reviewing this image for a visual designer sourcing assets for a project. Describe: what the image depicts, the mood and color palette, how the lighting and composition work, any text present in the image, whether there are any issues (artifacts, distortions), and how it could be used in a layout for an app or website. Be concise and practical. Respond only with your analysis as Markdown and absolutely no other text. Do not use emojis - use unicode if you need symbols.";
+var ANALYZE_PROMPT = 'You are reviewing this image for a visual designer sourcing assets for a project. Describe: what the image depicts, the mood and color palette, how the lighting and composition work, any text present in the image, whether there are any issues (artifacts, distortions), and how it could be used in a layout for an app or website. Be concise and practical. Respond only with your analysis as Markdown (starting with the title "Asset Review") and absolutely no other text. Do not use emojis - use unicode if you need symbols.';
 async function generateImageAssets(opts) {
   const { prompts, sourceImages, transparentBackground, onLog } = opts;
   const width = opts.width || 2048;

package/dist/index.js

@@ -3508,7 +3508,7 @@ var init_imageGenerator = __esm({
     init_runCli();
     init_analyzeImage();
     init_enhancePrompt();
-    ANALYZE_PROMPT = "You are reviewing this image for a visual designer sourcing assets for a project. Describe: what the image depicts, the mood and color palette, how the lighting and composition work, any text present in the image, whether there are any issues (artifacts, distortions), and how it could be used in a layout for an app or website. Be concise and practical. Respond only with your analysis as Markdown and absolutely no other text. Do not use emojis - use unicode if you need symbols.";
+    ANALYZE_PROMPT = 'You are reviewing this image for a visual designer sourcing assets for a project. Describe: what the image depicts, the mood and color palette, how the lighting and composition work, any text present in the image, whether there are any issues (artifacts, distortions), and how it could be used in a layout for an app or website. Be concise and practical. Respond only with your analysis as Markdown (starting with the title "Asset Review") and absolutely no other text. Do not use emojis - use unicode if you need symbols.';
   }
 });
 

package/dist/prompt/static/authoring.md

@@ -25,7 +25,7 @@ Remember: users care about look and feel as much as (and often more than) underl
 
 Write specs in natural, human language. Describe what the app does the way you'd explain it to a colleague. The spec renders with annotations hidden is a human-forward document that anyone can read. The spec with annotations visible is the agent-forward document that drives code generation. Keep the prose clean and readable — the user should never see raw CSS, code, or technical values in the prose. Write "square corners on all cards" not `border-radius: 0`. Write "no shadows" not `box-shadow: none`. Technical specifics belong in annotations.
 
-When the design expert provides specific implementation details — CSS values, spacing, font sizes, rotation angles, shadow definitions, animation timings, or things to pay special attention to or watch out for — capture them as annotations on the relevant prose. The design expert's recommendations are precise and intentional; don't summarize them into vague language. The prose describes the intent, the annotations preserve the exact values the coder needs:
+When the design expert provides specific implementation details — layout structure, CSS values, spacing, font sizes, rotation angles, shadow definitions, animation timings, or things to pay special attention to or watch out for — capture them as annotations on the relevant prose. The design expert's recommendations are precise and intentional; don't summarize them into vague language. The prose describes the intent, the annotations preserve the exact values the coder needs:
 
 ```markdown
 Cards float at varied angles with [rounded corners]{border-radius: 24px} on a pure black background.

package/dist/prompt/static/instructions.md

@@ -17,7 +17,7 @@
 - Pushing to main branch will trigger a deploy. The user presses the publish button in the interface to request publishing.
 
 ### Build Notes
-For complex tasks — especially an initial buildout from a spec or making multiple changes in a single turn — write a `.remy-notes.md` scratchpad in the project root. Use it to record decisions, keep a checklist of tasks, and reference data you'll need across multiple tool calls: design tokens, color values, typography specs, image URLs, what's been built so far, what's left. Read it back instead of restating everything in your messages. Delete it when your work is done.
+For complex tasks — especially an initial buildout from a spec or making multiple changes in a single turn — write a `.remy-notes.md` scratchpad in the project root. Use it to track progress: a checklist of what's been built and what's left, and decisions you've made. Read the spec files directly when you need reference data. Delete the notes file when your work is done.
 
 ## Communication
 The user can already see your tool calls, so most of your work is visible without narration. Focus text output on three things:

package/dist/prompt/static/team.md

@@ -12,7 +12,7 @@ Your designer. Consult for any visual decision — choosing a color, picking fon
 
 The design expert cannot see your conversation with the user, so include relevant context and requirements in your task. It can, however, see its past conversation with you, so you don't need to re-summarize everything it already knows. Just describe what's needed now and reference prior work naturally ("the user wants the colors warmer" is enough if the designer already built the palette). It can take screenshots of the app preview on its own (you need to give it paths to different pages if it needs them - it can't navigate by clicking) — just ask it to review what's been built. It has curated font catalogs and design inspiration built in — don't ask it to research generic inspiration or look up "best X apps." Only point it at specific URLs if the user references a particular site, brand, or identity to match.
 
-The designer will return concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions, as well as specific techniques, CSS properties, and other values. Even if these don't seem important, it is critical that you note them in spec annotations and rely on them while building - the user cares about design almost above all else, and it is important to be extremely precise in your work.
+The designer will return concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions, as well as specific techniques, CSS properties, animation timings, code snippets, and other values. Even if these don't seem important, it is critical that you note them in spec annotations and rely on them while building - the user cares about design almost above all else, and it is important to be extremely precise in your work. The designer can also return code-fenced typography, color schemes, and wireframes (self-contained HTML and CSS). Write these directly into specs for future reference.
 
 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.
 

package/dist/subagents/codeSanityCheck/prompt.md

@@ -20,7 +20,8 @@ These are things we already know about and have decided to accept:
 - Limited browser support for CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`)  - we accept this tradeoff
 - Libraries we know are actively maintained, don't bother checking:
   - swr
-  - framer-motion
+  - motion (formerly framer-motion — import from `motion/react`, not `framer-motion`)
+  - gsap (now fully free, including ScrollTrigger, FLIP, MorphSVG)
   - styled-components
   - @tabler/icons-react
   - streamdown
@@ -38,7 +39,11 @@ These are recurring mistakes the coding agent makes. If you see the conditions f
 
 - **Redundant userId on the auth table.** The auth table already has a platform-managed `id` column — that's the user ID. If the plan adds a `userId` column to the users/auth table, flag it.
 
-- **Too many granular API calls.** These apps are MVPs with small datasets. If the plan has separate method calls for every screen or sub-view (load profile, then load posts, then load post detail, then load comments), flag it. Favor fewer, fatter requests — a profile page that loads posts with full content means tapping a post is instant. A feed that includes comment previews and like state means the detail view renders from memory. Ideally there's one big batch call on first load that gets all the common data a user will need so subsequent navigation feels instant. Over-fetching at this scale is almost always the right call — users notice instant transitions, they don't notice a slightly larger payload.
+- **Too many granular API calls.** This is an important one and often counterintuitive for our developer who wants to be correct and do a Good Job as a software engineer. These apps all start as MVPs with small datasets (like literally a handful of users, if even). User experience and perceived speed/performance are far more valuable than normalization and good REST API design. It is much better to load a big bundle of data on app load and manage state locally with optimistic updates synced to the server than it is to hav eseparate method calls for every screen or subview (e.g., load profile, then load posts, then load post detail, then load comments rather than just hitting "/load" on initial load and have it all in a global state manager).
+
+Favor fewer, fatter requests — it makes things instant for the user. "Over-fetching" at this scale is almost always the right call — users notice instant transitions, they don't notice a slightly larger payload. 
+
+When a plan includes multiple screens/API calls, always note this item for the developer with a brief explanation of the rationale behind it.
 
 - **Wouter is not React Router.** The agent defaults to React Router patterns which silently break in wouter. Key differences: no `useNavigate()` (use `const [, setLocation] = useLocation()`), no `navigate(-1)` for back (use `window.history.back()`), no `element` prop on Route (use `component={Foo}` or children), no `<Routes>` (use `<Switch>` — without it all matching routes render simultaneously), no `<Navigate>` (use `<Redirect>`), no `<Outlet>` for nested routes (use `nest` prop on Route), and no `useSearchParams()` from react-router (wouter has its own version with a different setter API). If you see any of these React Router patterns in a wouter project, flag it.
 

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

@@ -3,26 +3,43 @@
 When done well, animation is one of the most powerful levers for elevating the design of an app. Every type of app benefits from animation - from delightful interactions to beautiful visual effects, but it is the mark of a great designer to know when and how to use animation effectively. Think about the type of app you are building and the ways in which animation can play a role. Animation must never be distracting or affect performance or usability - it should always serve to delight and add polish.
 
 There are two categories of animation and you should think of them separately:
-- Interaction animation: think button clicks, UI transitions, loading effects. Intetional, beautiful, unobtrusive interaction animation is a baseline requirement for any app. If done correctly, user might never even notice it - but they will certainly notice its absence or when it is overdone.
+- Interaction animation: think button clicks, UI transitions, loading effects. Intentional, beautiful, unobtrusive interaction animation is a baseline requirement for any app. If done correctly, users might never even notice it - but they will certainly notice its absence or when it is overdone.
 - 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: 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.
+- CSS scroll-driven animations (`animation-timeline: view()`) for scrollytelling. Scroll-driven animations that animate based on scrollport are very slick and look beautiful in landing pages.
+- Spring physics for natural-feeling motion. Specify spring parameters (stiffness, damping) rather than just saying "spring animation."
+- 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. Be very thoughtful and intentional.
 - Pay attention to timing, duration, speed, and layout shift - make sure animations are beautiful, especially if they involve text or elements the user is reading or interacting with.
 
+### Layout Animations
+Layout animations are what make apps feel native rather than web. When a card expands into a detail view, when a grid reflows as filters change, when a new item inserts into a list and everything else slides to make room — these transitions tell the user "the thing you were looking at is the same thing you're looking at now, it just moved."
+
+- **Shared-element transitions**: Use Motion's `layoutId` to animate an element smoothly between two positions in the DOM (e.g., a thumbnail in a grid expanding into a full detail view). Specify which properties animate and the easing.
+- **Route transitions**: The View Transitions API is now supported in all major browsers and gives native-feeling page transitions. React Router has built-in support. Use it for route changes where you want the old page to crossfade or slide into the new one.
+- **List/grid reflows**: When items are added, removed, or reordered, use Motion's `layout` prop or GSAP's FLIP plugin to animate every affected element to its new position rather than letting the DOM just snap.
+
+### Gesture-Driven Animation
+For any surface the user can drag, swipe, or pull, describe the physics — not just "make it draggable." The developer needs to know:
+
+- **Drag constraints**: How far can it travel? Does it snap to positions or move freely?
+- **Dismiss thresholds**: At what velocity or distance does a drag commit to dismissal vs. snapping back? (e.g., "dismiss if dragged past 40% of the sheet height or if release velocity exceeds 500px/s")
+- **Spring-back behavior**: When the user releases without hitting the threshold, what does the return feel like? Specify stiffness and damping.
+- **Overscroll/rubber-banding**: Does the element resist past its bounds, and how much?
+
 ### Libraries
-  - Prefer raw CSS animations when possible. 
-  - Animations must always be performant. Make sure to only animated GPU-constrained properties.
-  - Motion (aka Framer Motion) is the default for React for more complex animations.
+- Prefer raw CSS animations and transitions when possible. They're the most performant and simplest to maintain.
+- Motion (`motion/react`) is the default for React when CSS isn't enough — layout animations, gesture-driven interactions, spring physics, orchestrated sequences.
+- GSAP is fully free now (including ScrollTrigger, FLIP plugin, MorphSVG) and is the best choice for complex scroll-driven timelines, SVG animation, and framework-agnostic projects.
+- View Transitions API is native in all major browsers — use it for route/page transitions.
+- Only animate GPU-friendly properties (transform, opacity) whenever possible. Animating layout properties (width, height, top, left) causes reflows and jank.
 
-### Outdated Animations to Avoid
-- Never use Parallax scrolling as a primary pattern
-- Never use bounce/elastic easing
-- Never use heavy animation libraries for simple fades
-- Never get in the way of the user doing work - the user must never feel like the animations are preventing them from doing what they need to do.
+### Outdated Patterns to Avoid
+- Parallax scrolling as a primary pattern
+- Heavy animation libraries for simple fades (use CSS transitions)
+- Cartoonish bounce effects with exaggerated overshoot — spring physics should feel physical, not playful
+- Animations that block the user from doing work — the user must never feel like animations are preventing them from interacting
 
 ### Output
-When recommending layouts that involve motion, be verbose and intentional. Specify the exact techniques and parameters so the developer can implement correctly - it will try to be lazy if it thinks it can get away with it.
+When recommending layouts that involve motion, be verbose and intentional. Specify the exact techniques, parameters, easing curves, durations, and thresholds so the developer can implement correctly - they will try to be lazy if they think they can get away with it.

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

@@ -2,7 +2,7 @@
 
 Important: All images used in the app might be high resolution and high quality. If serving them via the mindstudio cdn, make sure to specify the ?dpr=3 param for retina displays.
 
-You have a powerful tool for generating high-quality images from any prompt: realistic photos, visalizations, textures, logos, icons and other elements, and more. Use it to create truly custom and beautiful designs. Be liberal with image generation - create multiple variants and choose the best one - AI image generation prompts are finnicky and unpredictable, you don't need to get it right the first generation. You can always edit or regenerate if the analysis seems off.
+You have a powerful tool for generating high-quality images from any prompt: realistic photos, visualizations, logos, icons and other elements, and more. Use it to create truly custom and beautiful designs. Be liberal with image generation - create multiple variants and choose the best one - AI image generation prompts are finnicky and unpredictable, you don't need to get it right the first generation. You can always edit or regenerate if the analysis seems off.
 
 When the design calls for imagery, generate actual images and provide their CDN URLs so the developer can use them immediately. Prefer images with strong subjects: people, scenes - dramatic, eye catching, and beautiful.
 
@@ -12,9 +12,9 @@ Do not provide images as "references" - images must be ready-to-use assets that
 
 ### Image generation
 
-Use `generateImages` to create images from scratch. The image generation model produces outstanding, high-quality results for everything from photorealistic images to illustrations, visualizations, graphics, and abstract/creative textures. You have full control over the output: style, composition, colors, mood. When generating multiple images, batch them in a single `generateImages` call — they run in parallel, you can generate up to 10 in one turn.
+Use `generateImages` to create images from scratch. The image generation model produces outstanding, high-quality results for everything from photorealistic images to illustrations, visualizations, and graphics. You have full control over the output: style, composition, colors, mood. When generating multiple images, batch them in a single `generateImages` call — they run in parallel, you can generate up to 10 in one turn.
 
-Set `transparentBackground: true` to produce transparent PNGs — the background is removed automatically after generation. Use this for isolated elements: product shots, objects, icons, mascots, illustrated elements, or anything that needs to be composited onto a layout rather than used as a full-frame image.
+Set `transparentBackground: true` to produce transparent PNGs — the background is removed automatically after generation. Use this for isolated elements: brand marks, layout components, objects, icons, mascots, illustrated elements, or anything that needs to be composited onto a layout rather than used as a full-frame image. Since `transparentBackground` applies to the entire batch, split your calls when you need a mix — one call for full-frame photos/backgrounds, a separate call with `transparentBackground: true` for isolated elements.
 
 Generated images are production assets, not mockups or concepts — they are hosted on MindStudio CDN at full resolution and will be used directly in the final interface.
 
@@ -47,19 +47,17 @@ Be thoughtful, careful, and intentional with your prompt - especially when descr
 
 You can produce two kinds of image assets:
 
-**Full-frame images** (the default) — photographs, textures, backgrounds, illustrations. These are full rectangular frames. The developer controls how they're used: cropping, blending, overlaying, masking with CSS. Generate a dramatic texture and the developer uses it as a card background with a blend mode. Generate an editorial photo and the developer overlays text on it for a hero section.
+**Full-frame images** (the default) — photographs and illustrations. These are full rectangular frames. The developer controls how they're used: cropping, overlaying, masking with CSS.
 
 **Isolated assets** (with `transparentBackground`) — cutout objects, product shots, app icons or interface icons, illustrated elements on transparent backgrounds. These are composited directly onto layouts, layered over other content, or placed inside cards and feature sections as standalone elements.
 
 Note: when analyzing images generated with `transparentBackground`, the transparent background will appear white to the vision analysis models. Don't mistake this for a white background — the image has an alpha channel and the background is transparent. Trust the generation parameters over what the analysis describes.
 
-Think of yourself as providing visual ingredients — both backgrounds and foreground elements — not finished UI.
-
 ### What makes good photos and images
 
 Remember: It's 2026. Everything is lifestyle and editorial these days. Even a landing page for a productivity tool or a SaaS product should feel like a magazine spread, not a tech blog. The era of sterile stock-photo-of-a-laptop-on-a-desk is over. People respond to beautiful, dramatic, emotionally resonant imagery.
 
-Default to photography with real subjects — people, scenes, moments, environments. Use editorial and fashion photography vocabulary in your prompts. When abstract art is the right call (textures, editorial collages, gradient art), make it bold and intentional, not generic gradient blobs.
+Default to photography with real subjects — people, scenes, moments, environments. Use editorial and fashion photography vocabulary in your prompts.
 
 #### Match style to context
 
@@ -69,7 +67,7 @@ The developer should never need to source their own imagery. Always provide URLs
 
 ### Icons and logos
 
-App icons and logos require work and thinking to get right.
+App icons and logos require work and thinking to get right. Prefer to use logos and icons as opposed to generic wordmarks when representing the app in UI (e.g., in navigation, on landing pages, login moments, etc).
 
 **What works:** Smooth 3D rendering in the style of 2026-era macOS/iOS app icons - apple emoji/nintendo style works really well for beautiful iconography. One clear object or symbol — rounded, immediately recognizable. Clean surfaces with soft lighting and gentle shadows. Two or three accent colors, not a rainbow. Always full bleed.
 
@@ -77,13 +75,13 @@ App icons and logos require work and thinking to get right.
 
 #### Open Graph Sharing Images
 
-Open Graph sharing images are visible when sharing the app on social media and messengers - they're often user's first impression of the app. Keep them simple and clean - think like Figma cover images, or the kind of content you'd see on a billboard for the app. Simple, powerful, clear. Use strong text that will be visible at smaller sizes (think of someone seeing the image in imessage, for example). Generate the image at 4096 × 2150 and return the CDN URL with ?w=1200&h=630&fit=crop.
+OG images show up in iMessage, Slack, Twitter, etc. at small sizes. They're a mood piece, not a messaging opportunity. Keep text minimal: the app name and at most a short tagline (three to five words). Think App Store feature card — one beautiful composition that makes someone want to tap. The text should feel integrated into the scene, not pasted on a background. Generate at 4096 × 2150 and return the CDN URL with `?w=1200&h=630&fit=crop`.
 
 ### 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.
 
-Transparent assets open up new layout possibilities: a mascot or other object, images for empty states, onboarding flows, or full-screen loading states. When the design calls for layered compositions, generate the elements separately with transparent backgrounds rather than trying to compose everything into a single flat image.
+Transparent assets open up layout possibilities: a mascot or other object, images for empty states, onboarding flows. When the design calls for layered compositions, generate the elements separately with transparent backgrounds rather than trying to compose everything into a single flat image.
 
 ### CDN image transforms
 

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

@@ -46,4 +46,4 @@ Backgrounds create atmosphere. Solid white or solid gray is the safe default and
 
 ### Output
 
-When proposing layouts, describe both layers: the spatial architecture (regions, fixed vs. fluid, scroll behavior, responsive strategy) and the visual composition (proportions, spacing, visual techniques). Specify exact ratios, positions, and anything else the developer needs to correctly implement the vision.
+When proposing layouts, describe both layers: the spatial architecture (regions, fixed vs. fluid, scroll behavior, responsive strategy) and the visual composition (proportions, spacing, visual techniques). Specify exact ratios, positions, and anything else the developer needs to correctly implement the vision. Include dedicated sections in your reponse describing spacing and layout in detail.

package/dist/subagents/designExpert/prompts/ui-patterns.md

@@ -36,14 +36,17 @@ Pay close attention to text streaming when the AI replies - it should feel natur
 
 ### Wireframes
 
-When a pattern or interaction is hard to convey in words alone — a core component, an animation sequence, a swipe gesture, a layout grid — you can include a small interactive wireframe to demonstrate it. Use a markdown code fence with `wireframe` as the type. Start with a YAML frontmatter block (`name` and `description`) to identify the component, then the self-contained HTML+CSS prototype.
+When a pattern or interaction is hard to convey in words alone — a core component, an animation sequence, a swipe gesture, a layout grid — include a small interactive wireframe to demonstrate it. Use a markdown code fence with `wireframe` as the type. Start with a YAML frontmatter block (`name` and `description`) to identify the component, then the self-contained HTML+CSS prototype.
 
-Use wireframes instead of ASCII art and code-block diagrams you might otherwise reach for when trying to show a layout or interaction. Wireframes are better because the developer can actually see and interact with the result. Like those diagrams, they isolate one small piece: a single card component, a button animation, a transition, a grid layout. Each wireframe should be around 60-80 lines of HTML+CSS — if you're past 100 lines, you're building too much. These are not screens, flows, or multi-step prototypes. They render in a small iframe and should look complete at that scale. Most of your communication should be in words - wireframes are simply another tool when you need them. Never build out full screens or pages in wireframes, even if you are asked to - this is critically important.
+Use wireframes instead of ASCII art and code-block diagrams you might otherwise reach for when trying to show a layout or interaction. Wireframes are better because the developer can actually see and interact with the result. Like those diagrams, they isolate one small piece: a single card component, a button animation, a transition, a grid layout. Each wireframe should be around 60-80 lines of HTML+CSS — if you're past 100 lines, you're building too much. These are not screens, flows, or multi-step prototypes. They render in a small iframe and should look complete at that scale. Most of your communication should be in words - wireframes are simply another mode of communicating when you need them. Never build out full screens or pages in wireframes, even if you are asked to - this is critically important.
 
-Remember, never use ascii art or code-block diagrams to describe layouts - always use wireframes.
+Remember, never use ascii art or code-block diagrams to describe layouts - always use wireframes. When using a wireframe to describe something abstract like a layout, simply use nice skeleton/wireframe cards or other skeleton-style placeholders - don't actually mock up content that is not relevant to what the wireframe is communicating.
 
 The wireframe code will be rendered in a transparent iframe. Don't fill the viewport or add a background color to the body. Place the component at a natural size in a card with a background color that is centered vertically and horizontally in the viewport. Keep the component tight and self-contained. The iframe is for the component only — no annotations, labels, or explanatory text inside it. Put your notes and implementation guidance in the markdown around the wireframe. Wireframes can be interactive and are especially useful for demonstrating states, animations, effects, and transitions. If your wireframe has triggers or states, include a small "play" control button within the frame (make sure to allow reply/reset for all interactivity). No images - these are functional prototypes meant to demonstrate feel and behavior, not visual comps.
 
+Wireframes are vanilla HTML/CSS/JS (no React). For animations beyond CSS, use GSAP via CDN:
+`<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>`
+
 ```wireframe
 ---
 name: Feed Post Card

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

@@ -63,7 +63,9 @@ For app icons and logos, the goal is something that reads clearly at phone home
 
 #### Open Graph Sharing Images
 
-Open Graph sharing images are visible when sharing the app on social media and messengers - they're often user's first impression of the app. Keep them simple and clean - think like Figma cover images, or the kind of content you'd see on a billboard for the app. Simple, powerful, clear. Use strong text that will be visible at smaller sizes (think of someone seeing the image in imessage, for example).
+OG images are often a user's first impression of the app — they show up in iMessage, Slack, Twitter, etc. at small sizes. Keep text minimal: the app name and at most a short tagline (three to five words). This is a mood piece, not a messaging opportunity. Think App Store feature card — one beautiful composition that makes someone want to tap.
+
+Apply the same material/lighting/color density as photography prompts. The text should feel integrated into the scene — typeset within the composition, not pasted on top. Describe the typography treatment (weight, size, color, position) as part of the overall image, and describe how the background interacts with the text (glow, depth, contrast). The whole image should read as one cohesive graphic, not layers.
 
 ## Output
 

package/package.json

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