@mindstudio-ai/remy 0.1.98 → 0.1.100
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/automatedActions/buildFromInitialSpec.md +3 -1
- package/dist/headless.js +1 -1
- package/dist/index.js +1 -1
- package/dist/prompt/compiled/auth.md +1 -0
- package/dist/prompt/static/authoring.md +3 -1
- package/dist/prompt/static/coding.md +1 -1
- package/dist/prompt/static/instructions.md +1 -1
- package/dist/subagents/designExpert/prompts/images.md +8 -10
- package/dist/subagents/designExpert/prompts/layout.md +1 -1
- package/dist/subagents/designExpert/tools/images/enhance-image-prompt.md +3 -1
- package/package.json +1 -1
|
@@ -12,7 +12,9 @@ If you are building a web frontend, consult `visualDesignExpert` for guidance an
|
|
|
12
12
|
|
|
13
13
|
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 - don't forget to update the page metadata on index.html too.
|
|
14
14
|
|
|
15
|
-
When code generation is complete,
|
|
15
|
+
When code generation is complete, do a polish pass before verifying. Re-read the spec annotations and the design expert's guidance, then walk through each frontend file looking for design details that got skipped in the initial build: animations, transitions, hover states, micro-interactions, spring physics, entrance reveals, gesture handling, layout issues, and anything else. The initial build prioritizes getting everything connected and functional, but this pass closes the gap between "it works" and "it feels great." In many ways this is the most important part of the initial build, as the user's first experience of the deliverable will set their expectations for every iteration that follows. Don't mess this up.
|
|
16
|
+
|
|
17
|
+
Then verify:
|
|
16
18
|
- First, run use `runScenario` to seed test data, then use `runMethod` to confirm a method works
|
|
17
19
|
- If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
|
|
18
20
|
- 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.
|
package/dist/headless.js
CHANGED
|
@@ -3566,7 +3566,7 @@ ${brief}
|
|
|
3566
3566
|
}
|
|
3567
3567
|
|
|
3568
3568
|
// src/subagents/designExpert/tools/images/imageGenerator.ts
|
|
3569
|
-
var ANALYZE_PROMPT =
|
|
3569
|
+
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.';
|
|
3570
3570
|
async function generateImageAssets(opts) {
|
|
3571
3571
|
const { prompts, sourceImages, transparentBackground, onLog } = opts;
|
|
3572
3572
|
const width = opts.width || 2048;
|
package/dist/index.js
CHANGED
|
@@ -3508,7 +3508,7 @@ var init_imageGenerator = __esm({
|
|
|
3508
3508
|
init_runCli();
|
|
3509
3509
|
init_analyzeImage();
|
|
3510
3510
|
init_enhancePrompt();
|
|
3511
|
-
ANALYZE_PROMPT =
|
|
3511
|
+
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.';
|
|
3512
3512
|
}
|
|
3513
3513
|
});
|
|
3514
3514
|
|
|
@@ -129,6 +129,7 @@ await auth.logout(); // clears session
|
|
|
129
129
|
|
|
130
130
|
```typescript
|
|
131
131
|
auth.phone.countries // ~180 countries with { code, dialCode, name, flag }
|
|
132
|
+
// Key selects by country code (US, CA, BB), not dial code — multiple countries share +1
|
|
132
133
|
auth.phone.detectCountry() // guess from timezone, e.g. 'US'
|
|
133
134
|
auth.phone.toE164('5551234567', 'US') // '+15551234567'
|
|
134
135
|
auth.phone.format('+15551234567') // '+1 (555) 123-4567'
|
|
@@ -25,7 +25,7 @@ Remember: users care about look and feel as much as (and often more than) underl
|
|
|
25
25
|
|
|
26
26
|
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.
|
|
27
27
|
|
|
28
|
-
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
|
|
28
|
+
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 — it is critical that you capture them in full within the spec. 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:
|
|
29
29
|
|
|
30
30
|
```markdown
|
|
31
31
|
Cards float at varied angles with [rounded corners]{border-radius: 24px} on a pure black background.
|
|
@@ -37,6 +37,8 @@ box-shadow: 0 8px 32px rgba(0,0,0,0.3) for floating depth
|
|
|
37
37
|
|
|
38
38
|
When you have image URLs (from the design expert), embed them directly in the spec using markdown image syntax. Write descriptive alt text that captures what the image actually depicts (this helps accessibility and helps the coding agent understand the image without loading it). Use the surrounding prose to explain the design intent — what the image is for, how it should be used in the layout, and why it was chosen.
|
|
39
39
|
|
|
40
|
+
When the design expert provides wireframes, include them directly in the spec for future reference.
|
|
41
|
+
|
|
40
42
|
```markdown
|
|
41
43
|
### Hero Section
|
|
42
44
|
|
|
@@ -43,7 +43,7 @@ For any work involving AI models, external actions (web scraping, email, SMS), o
|
|
|
43
43
|
- Use container queries for components that need to adapt to their container rather than the viewport.
|
|
44
44
|
|
|
45
45
|
### State Management
|
|
46
|
-
- Calls to methods introduce latency. When building web frontends that load data from methods,
|
|
46
|
+
- Calls to methods introduce latency. When building web frontends that load data from methods, front-load as much data as you can in a single API request - e.g., when possible, load a large data object into a central store and use that to render sub-screens in an app, rather than an API call on every screen. User experience and perceived speed/performance are far more valuable than normalization and good REST API design.
|
|
47
47
|
|
|
48
48
|
### Dependencies
|
|
49
49
|
Before installing a package you haven't used in this project, do a quick web search to confirm it's still the best option. The JavaScript ecosystem moves fast — the package you remember from training may have been superseded by something smaller, faster, or better maintained. A 10-second search beats debugging a deprecated library.
|
|
@@ -17,7 +17,7 @@
|
|
|
17
17
|
- Pushing to main branch will trigger a deploy. The user presses the publish button in the interface to request publishing.
|
|
18
18
|
|
|
19
19
|
### Build Notes
|
|
20
|
-
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
|
|
20
|
+
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.
|
|
21
21
|
|
|
22
22
|
## Communication
|
|
23
23
|
The user can already see your tool calls, so most of your work is visible without narration. Focus text output on three things:
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
5
|
-
You have a powerful tool for generating high-quality images from any prompt: realistic photos,
|
|
5
|
+
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.
|
|
6
6
|
|
|
7
7
|
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.
|
|
8
8
|
|
|
@@ -12,9 +12,9 @@ Do not provide images as "references" - images must be ready-to-use assets that
|
|
|
12
12
|
|
|
13
13
|
### Image generation
|
|
14
14
|
|
|
15
|
-
Use `generateImages` to create images from scratch. The image generation model produces outstanding, high-quality results for everything from photorealistic images to illustrations, visualizations,
|
|
15
|
+
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.
|
|
16
16
|
|
|
17
|
-
Set `transparentBackground: true` to produce transparent PNGs — the background is removed automatically after generation. Use this for isolated elements:
|
|
17
|
+
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.
|
|
18
18
|
|
|
19
19
|
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.
|
|
20
20
|
|
|
@@ -47,19 +47,17 @@ Be thoughtful, careful, and intentional with your prompt - especially when descr
|
|
|
47
47
|
|
|
48
48
|
You can produce two kinds of image assets:
|
|
49
49
|
|
|
50
|
-
**Full-frame images** (the default) — photographs
|
|
50
|
+
**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.
|
|
51
51
|
|
|
52
52
|
**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.
|
|
53
53
|
|
|
54
54
|
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.
|
|
55
55
|
|
|
56
|
-
Think of yourself as providing visual ingredients — both backgrounds and foreground elements — not finished UI.
|
|
57
|
-
|
|
58
56
|
### What makes good photos and images
|
|
59
57
|
|
|
60
58
|
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.
|
|
61
59
|
|
|
62
|
-
Default to photography with real subjects — people, scenes, moments, environments. Use editorial and fashion photography vocabulary in your prompts.
|
|
60
|
+
Default to photography with real subjects — people, scenes, moments, environments. Use editorial and fashion photography vocabulary in your prompts.
|
|
63
61
|
|
|
64
62
|
#### Match style to context
|
|
65
63
|
|
|
@@ -69,7 +67,7 @@ The developer should never need to source their own imagery. Always provide URLs
|
|
|
69
67
|
|
|
70
68
|
### Icons and logos
|
|
71
69
|
|
|
72
|
-
App icons and logos require work and thinking to get right.
|
|
70
|
+
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).
|
|
73
71
|
|
|
74
72
|
**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.
|
|
75
73
|
|
|
@@ -77,13 +75,13 @@ App icons and logos require work and thinking to get right.
|
|
|
77
75
|
|
|
78
76
|
#### Open Graph Sharing Images
|
|
79
77
|
|
|
80
|
-
|
|
78
|
+
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`.
|
|
81
79
|
|
|
82
80
|
### When to use images
|
|
83
81
|
|
|
84
82
|
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.
|
|
85
83
|
|
|
86
|
-
Transparent assets open up
|
|
84
|
+
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.
|
|
87
85
|
|
|
88
86
|
### CDN image transforms
|
|
89
87
|
|
|
@@ -46,4 +46,4 @@ Backgrounds create atmosphere. Solid white or solid gray is the safe default and
|
|
|
46
46
|
|
|
47
47
|
### Output
|
|
48
48
|
|
|
49
|
-
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.
|
|
49
|
+
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.
|
|
@@ -63,7 +63,9 @@ For app icons and logos, the goal is something that reads clearly at phone home
|
|
|
63
63
|
|
|
64
64
|
#### Open Graph Sharing Images
|
|
65
65
|
|
|
66
|
-
|
|
66
|
+
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.
|
|
67
|
+
|
|
68
|
+
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.
|
|
67
69
|
|
|
68
70
|
## Output
|
|
69
71
|
|