@mindstudio-ai/remy 0.1.26 → 0.1.28

package/dist/prompt/.notes.md

@@ -142,7 +142,6 @@ The intro framing ("you have a lot on your plate") gives the model permission to
 
 | Agent | Role | Tools | Context |
 |---|---|---|---|
-| `visualDesignExpert` | Visual design decisions | searchGoogle, fetchUrl, analyzeReferenceImageOrUrl, screenshot, searchProductScreenshots, generateImages | Spec files + sampled fonts + sampled inspiration |
 | `productVision` | Roadmap ownership & product strategy | writeRoadmapItem, updateRoadmapItem, deleteRoadmapItem | Spec files + current roadmap |
 | `sdkConsultant` | MindStudio SDK architecture | None (shells out to `mindstudio ask` CLI) | None (external agent) |
 | `codeSanityCheck` | Pre-build review | readFile, grep, glob, searchGoogle, fetchUrl, askMindStudioSdk, bash (readonly) | Spec files |

package/dist/prompt/compiled/tables.md

@@ -20,6 +20,23 @@ export const Vendors = db.defineTable<Vendor>('vendors');
 
 One export per file. The export name is referenced in `mindstudio.json` and imported in methods. Only define your own columns in the interface — do not add `id`, `created_at`, `updated_at`, or `last_updated_by` (they're provided automatically, see below).
 
+### Table Options
+
+`defineTable<T>()` accepts an optional second argument with table-level configuration:
+
+```typescript
+export const Users = db.defineTable<User>('users', {
+  unique: [['email']],
+  defaults: { role: 'member', status: 'active' },
+});
+```
+
+- **`unique`** — `(keyof T & string)[][]` — Column groups that form unique constraints. Each entry is a string array of column names. These are required for `upsert()` (see below). Schema sync on the platform creates the actual SQLite UNIQUE indexes.
+  - Single column: `[['email']]`
+  - Compound: `[['userId', 'orgId']]`
+  - Multiple constraints: `[['email'], ['slug']]`
+- **`defaults`** — `Partial<T>` — Default values applied client-side in `push()` and `upsert()` before building the INSERT. Explicit values in the input override defaults.
+
 ### Column Types
 
 | TypeScript type | SQLite type | Notes |
@@ -79,6 +96,30 @@ const vendors = await Vendors.push([
 ]);
 ```
 
+If the table has `defaults` configured, missing fields are filled in automatically. Explicit values override defaults.
+
+### Upsert (Insert or Update)
+
+```typescript
+// Insert if no conflict on 'email', otherwise update the existing row
+const user = await Users.upsert('email', {
+  email: 'alice@acme.com',
+  name: 'Alice',
+  role: 'admin',
+});
+
+// Compound conflict key — pass an array
+const membership = await Memberships.upsert(['userId', 'orgId'], {
+  userId: user.id,
+  orgId: org.id,
+  role: 'member',
+});
+```
+
+`upsert(conflictKey, data)` generates `INSERT ... ON CONFLICT(...) DO UPDATE SET ...` using SQLite's `excluded.` syntax. All non-conflict columns are updated on conflict. Returns a `Mutation<T>` — works with `await` standalone or inside `db.batch()`, same as `push()` and `update()`.
+
+The conflict key must match a declared `unique` constraint on the table. Throws `MindStudioError` with code `no_unique_constraint` if no match.
+
 ### Reading Records
 
 ```typescript
@@ -162,9 +203,20 @@ db.ago(db.days(7) + db.hours(12)) // composable — 7.5 days ago
 Invoices.filter(i => i.dueDate < db.ago(db.days(30)))
 ```
 
+### Error Handling on Queries
+
+Both `Query<T>` and `Mutation<T>` support `.then()` and `.catch()` directly:
+
+```typescript
+const user = await Users.upsert('email', data).catch(err => {
+  if (err.code === 'no_unique_constraint') { /* ... */ }
+  throw err;
+});
+```
+
 ### Batching
 
-`db.batch()` combines multiple operations into a single HTTP round-trip. Every `await` on a table operation is a network call, so batching is critical for performance. Use it whenever you have multiple reads, writes, or a mix of both:
+`db.batch()` combines multiple operations into a single HTTP round-trip. Every `await` on a table operation is a network call, so batching is critical for performance. Use it whenever you have multiple reads, writes, or a mix of both. `upsert()` works in batches just like `push()` and `update()`:
 
 ```typescript
 // Reads: fetch related data in one call instead of sequential awaits

package/dist/prompt/static/authoring.md

@@ -25,6 +25,16 @@ Users often care about look and feel as much as (or more than) underlying data s
 
 Write specs in natural, human language. Describe what the app does the way you'd explain it to a colleague. The spec rendered 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:
+
+```markdown
+Cards float at varied angles with [rounded corners]{border-radius: 24px} on a pure black background.
+~~~
+transform: rotate() with values between -15deg and 15deg, varied per card
+box-shadow: 0 8px 32px rgba(0,0,0,0.3) for floating depth
+~~~
+```
+
 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.
 
 ```markdown

package/dist/prompt/static/instructions.md

@@ -6,6 +6,7 @@
 
 ## Principles
 - The spec in `src/` is the source of truth. When in doubt, consult the spec before making code changes. When behavior changes, update the spec first.
+- Always keep the spec up to date after making changes to the code, especially when adding features or building things from the roadmap.
 - Change only what the task requires. Match existing styles. Keep solutions simple.
 - Read files before editing them. Understand the context before making changes.
 - When the user asks you to make a change, execute it fully — all steps, no pausing for confirmation. Use `confirmDestructiveAction` to gate before destructive or irreversible actions (e.g., deleting data, resetting the database). For large changes that touch many files or involve significant design decisions, use `presentPlan` to get user approval first — but only when the scope genuinely warrants it or the user asks to see a plan. Most work should be done autonomously.
@@ -17,7 +18,7 @@
 ## Communication
 The user can already see your tool calls, so most of your work is visible without narration. Focus text output on three things:
 - **Decisions that need input.** Questions, tradeoffs, ambiguity that blocks progress.
-- **Milestones.** What you built, what it looks like, what changed. Summarize in plain language rather than listing a per-file changelog. When a sub-agent returns visual results (images, design direction), share them with the user inline before continuing your work — let them see what's been created while you keep going.
+- **Milestones.** What you built, what it looks like, what changed. Summarize in plain language rather than listing a per-file changelog.
 - **Errors or blockers.** Something failed or the approach needs to shift.
 
 Skip the rest: narrating what you're about to do, restating what the user asked, explaining tool calls they can already see.

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 all relevant context and requirements in your task. It can take screenshots of the app preview on its own — just ask it to review what's been built.
 
-Returns concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions.
+Returns concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions. 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.
 
 Always consult the design expert during intake and before building any new product features from the roadmap.
 

package/dist/static/authoring.md

@@ -25,6 +25,16 @@ Users often care about look and feel as much as (or more than) underlying data s
 
 Write specs in natural, human language. Describe what the app does the way you'd explain it to a colleague. The spec rendered 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:
+
+```markdown
+Cards float at varied angles with [rounded corners]{border-radius: 24px} on a pure black background.
+~~~
+transform: rotate() with values between -15deg and 15deg, varied per card
+box-shadow: 0 8px 32px rgba(0,0,0,0.3) for floating depth
+~~~
+```
+
 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.
 
 ```markdown

package/dist/static/instructions.md

@@ -6,6 +6,7 @@
 
 ## Principles
 - The spec in `src/` is the source of truth. When in doubt, consult the spec before making code changes. When behavior changes, update the spec first.
+- Always keep the spec up to date after making changes to the code, especially when adding features or building things from the roadmap.
 - Change only what the task requires. Match existing styles. Keep solutions simple.
 - Read files before editing them. Understand the context before making changes.
 - When the user asks you to make a change, execute it fully — all steps, no pausing for confirmation. Use `confirmDestructiveAction` to gate before destructive or irreversible actions (e.g., deleting data, resetting the database). For large changes that touch many files or involve significant design decisions, use `presentPlan` to get user approval first — but only when the scope genuinely warrants it or the user asks to see a plan. Most work should be done autonomously.
@@ -17,7 +18,7 @@
 ## Communication
 The user can already see your tool calls, so most of your work is visible without narration. Focus text output on three things:
 - **Decisions that need input.** Questions, tradeoffs, ambiguity that blocks progress.
-- **Milestones.** What you built, what it looks like, what changed. Summarize in plain language rather than listing a per-file changelog. When a sub-agent returns visual results (images, design direction), share them with the user inline before continuing your work — let them see what's been created while you keep going.
+- **Milestones.** What you built, what it looks like, what changed. Summarize in plain language rather than listing a per-file changelog.
 - **Errors or blockers.** Something failed or the approach needs to shift.
 
 Skip the rest: narrating what you're about to do, restating what the user asked, explaining tool calls they can already see.

package/dist/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 all relevant context and requirements in your task. It can take screenshots of the app preview on its own — just ask it to review what's been built.
 
-Returns concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions.
+Returns concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions. 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.
 
 Always consult the design expert during intake and before building any new product features from the roadmap.
 

package/dist/subagents/.notes-background-agents.md

@@ -0,0 +1,80 @@
+# Background Agent Execution — Design Doc
+
+Draft design for allowing sub-agents to return early and continue working in the background.
+
+## The problem
+
+Some sub-agent tasks don't need to block Remy's turn. Product vision seeding roadmap items, for example — Remy needs the high-level plan to continue, but doesn't need to wait for all 15 files to be written. Currently, Remy blocks until the sub-agent finishes completely.
+
+## Design
+
+### Two new tools available to sub-agents
+
+**`returnAndContinueInBackground`**
+- Input: `{ response: string }` — the text to return to Remy immediately
+- Called mid-loop by the sub-agent when it has enough to unblock Remy
+- Resolves the parent tool promise with the response text
+- The sub-agent loop continues running in the background
+- All subsequent events emitted with `background: true` flag
+
+**`finishBackgroundWork`**
+- Input: `{ result: string, silent: boolean }` — final outcome report
+- Called at the end of background work
+- `silent: true` — queue a notification for Remy's next turn (hidden message)
+- `silent: false` — trigger an automated message to wake Remy immediately
+- Failures should generally use `silent: false` so Remy can address them
+
+### Runner changes
+
+The runner needs to support a split lifecycle:
+
+1. Normal loop execution until `returnAndContinueInBackground` is called
+2. At that point, resolve the outer promise with `{ text: response, messages: [...so far] }`
+3. Continue the loop in a detached async context (own AbortController, not tied to Remy's turn)
+4. The `emit` wrapper adds `background: true` to all events after the split point
+5. When the sub-agent finishes (naturally or via `finishBackgroundWork`):
+   - Update `subAgentMessages` on the original tool block in `state.messages`
+   - Save the session
+   - If not silent, inject an automated message to trigger a new Remy turn
+
+### AgentEvent changes
+
+Add optional `background?: boolean` to all event types that have `parentToolId`. The frontend uses this to render background work differently (collapsed, subtle indicator, etc.).
+
+### History / subAgentMessages
+
+The `subAgentMessages` array on the tool content block gets updated in two phases:
+1. At `returnAndContinueInBackground` time — messages so far are attached (captured in the early return)
+2. At background completion — the full message array replaces the partial one, session is saved
+
+A `backgroundStartIndex` on the tool content block marks where the early return happened in the messages array, so the frontend knows which messages were "live" vs "background."
+
+### Notification queue
+
+The headless layer maintains a notification queue:
+- Background agents push to it when they finish (via `finishBackgroundWork`)
+- On next `runTurn`, headless flushes queued notifications as prepended hidden messages
+- If `silent: false`, headless also sends an automated message to trigger a new turn immediately
+
+### Process management
+
+The headless layer tracks active background agents:
+- `get_background_agents` action → returns list with id, name, startedAt, status
+- `cancel_background_agent` action → aborts a specific background agent
+- The frontend can show active background work and let users kill dangling agents
+
+### Which sub-agents would use this?
+
+- **productVision** — return lane summary immediately, write roadmap files in background (silent)
+- **designExpert** — could return font/color recommendations immediately, generate images in background (silent)
+- **codeSanityCheck** — probably NOT a candidate, Remy needs the advice before proceeding
+- **browserAutomation** — probably NOT a candidate, results inform Remy's next action
+
+### What to build (ordered)
+
+1. `returnAndContinueInBackground` and `finishBackgroundWork` tool definitions
+2. Runner split-lifecycle support (detached async continuation)
+3. `background: true` flag on AgentEvent types
+4. Notification queue in headless layer
+5. Background agent process tracking in headless layer
+6. Update productVision prompt to use `returnAndContinueInBackground`

package/dist/subagents/browserAutomation/prompt.md

@@ -1,6 +1,7 @@
 You are a browser smoke test agent. You verify that features work end to end by interacting with the live preview. Focus on outcomes: does the feature work? Did the expected content appear? Just do the thing and see if it worked.
 
-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 coding agent's name is Remy, so use that and the email remy@mindstudio.ai for any testing that requires a name or email.
+## Testiner 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 coding agent's name is Remy, so use that and the email remy@mindstudio.ai as the basis for any testing that requires a persona.
 
 ## Snapshot format
 
@@ -21,9 +22,12 @@ Each interactive element has a `[ref=eN]` you can use to target it.
 - `snapshot`: Get the current page state. Always do this first and after action batches to verify results. Waits for network requests to settle.
 - `click`: Click an element. The cursor animates to it, then dispatches full pointer/mouse/click events.
 - `type`: Type text into an input. Characters appear one at a time. Set `clear: true` to clear the field first.
+- `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.
 - `evaluate`: Run arbitrary JavaScript in the page and return the result.
-- `screenshot`: Capture a screenshot of the current page. Returns a CDN URL with dimensions. Separate tool call (not a browserCommand step).
+- `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.
+- `screenshot`: Full-page viewport-stitched screenshot. Returns base64 JPEG with dimensions. Available both as a browserCommand step (useful at the end of an action batch) and as a separate tool call (returns a CDN URL).
 
 ## Element targeting (tried in order)
 
@@ -78,6 +82,37 @@ Navigate to a sub-page and verify content:
 }
 ```
 
+Select a dropdown option and screenshot the result:
+```json
+{
+  "steps": [
+    { "command": "select", "label": "Country", "option": "United States" },
+    { "command": "screenshot" }
+  ]
+}
+```
+
+Navigate to a sub-page and interact with it:
+```json
+{
+  "steps": [
+    { "command": "navigate", "url": "/quiz" },
+    { "command": "wait", "text": "what's your aura?", "timeout": 8000 },
+    { "command": "type", "ref": "e3", "text": "blue" },
+    { "command": "screenshot" }
+  ]
+}
+```
+
+Check computed styles on an element:
+```json
+{
+  "steps": [
+    { "command": "styles", "text": "Sign Up", "properties": ["backgroundColor", "borderRadius", "boxShadow"] }
+  ]
+}
+```
+
 Check a count with evaluate:
 ```json
 {

package/dist/subagents/codeSanityCheck/prompt.md

@@ -17,6 +17,11 @@ Most things are fine. These are fast-moving products built by non-technical user
 These are things we already know about and have decided to accept:
 
 - Limited browser support for `oklch` gradients using `in <colorspace>` syntax — we accept the compatibility tradeoff for better color quality
+- 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
+  - styled-components
 
 ### Common pitfalls (always flag these)
 

package/dist/subagents/designExpert/.notes.md

@@ -242,7 +242,7 @@ Google Images is explicitly excluded — too much noise/junk for design work.
 - **Font catalog** — 105 fonts (80 Fontshare + 14 Google Fonts + 11 Open Foundry) with 51 curated pairings, compiled in `data/fonts.json`. Runtime-sampled per invocation.
 - **Design inspiration** — Godly screenshots rehosted on MindStudio CDN, pre-analyzed via vision model, compiled in `data/inspiration.json`. Runtime-sampled per invocation. Compilation script at `data/compile-inspiration.sh`.
 - **Runtime sampling** — `prompt.ts` samples 15 fonts + 5 pairings + 5 inspiration images per invocation.
-- **Tools** — searchGoogle, fetchUrl, analyzeReferenceImageOrUrl, screenshot, searchProductScreenshots, generateImages.
+- **Tools** — searchGoogle, fetchUrl, analyzeReferenceImageOrUrl, screenshot, generateImages.
 - **Prompt** — split into files in `prompts/` (identity, color, animation, layout, icons, images, resources, instructions, frontend-design-notes), assembled via template includes.
 - **Spec context** — automatically injected via `loadSpecContext()` from `subagents/common/context.ts`. Agent sees the full project spec without Remy summarizing.
 - **Image generation** — Seedream 4.5 via `generateImages` tool. Prompt guidance emphasizes: style/medium first, then subject; avoid hex codes (rendered as text); generate visual ingredients not UI components; default to real subjects over abstract.
@@ -251,7 +251,7 @@ Google Images is explicitly excluded — too much noise/junk for design work.
 ## Changes from initial design
 
 - Removed stock photo search (Pexels) and image editing tools — AI generation produces better bespoke results.
-- Removed Google Images for design inspiration — too much noise. Added `searchProductScreenshots` for real product UI research.
+- Removed Google Images for design inspiration — too much noise.
 - Consolidated `analyzeImage`, `analyzeDesignReference`, and `screenshotAndAnalyze` into single `analyzeReferenceImageOrUrl` tool that auto-detects image URLs vs website URLs.
 - Added `screenshot` tool (external, sandbox-resolved) so the agent can capture the app preview directly.
 - Font examples in all Remy prompts changed from Google Fonts (DM Sans) to Fontshare (Satoshi) to avoid reinforcing AI defaults.

package/dist/subagents/designExpert/data/compile-font-descriptions.sh

@@ -0,0 +1,125 @@
+#!/usr/bin/env bash
+#
+# Analyze font specimen images and write descriptions into fonts.json.
+#
+# Reads each font from fonts.json, looks for a matching specimen image
+# in specimens/fonts/{slug}.png, runs analyze-image, and writes the
+# description back to the font's "description" field.
+#
+# Run: bash src/subagents/designExpert/data/compile-font-descriptions.sh
+# Supports resuming — skips fonts that already have a description.
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+FONTS_FILE="$SCRIPT_DIR/fonts.json"
+SPECIMENS_BASE="https://i.mscdn.ai/remy-font-specimens/fonts"
+PROMPT_FILE="$SCRIPT_DIR/../prompts/tool-prompts/font-analysis.md"
+
+if [ ! -f "$PROMPT_FILE" ]; then
+  echo "Error: $PROMPT_FILE not found"
+  exit 1
+fi
+PROMPT=$(cat "$PROMPT_FILE")
+
+if [ ! -f "$FONTS_FILE" ]; then
+  echo "Error: $FONTS_FILE not found"
+  exit 1
+fi
+
+# Get fonts that need descriptions
+SLUGS=$(python3 -c "
+import json
+data = json.load(open('$FONTS_FILE'))
+for f in data['fonts']:
+    if not f.get('description'):
+        print(f['slug'])
+")
+
+TOTAL=$(python3 -c "import json; print(len(json.load(open('$FONTS_FILE'))['fonts']))")
+DONE=$(python3 -c "import json; print(sum(1 for f in json.load(open('$FONTS_FILE'))['fonts'] if f.get('description')))")
+echo "Font descriptions: $DONE/$TOTAL already done"
+
+if [ -z "$SLUGS" ]; then
+  echo "All fonts already have descriptions."
+  exit 0
+fi
+
+REMAINING=$(echo "$SLUGS" | wc -l | tr -d ' ')
+echo "Processing $REMAINING remaining fonts..."
+
+TMPDIR=$(mktemp -d)
+
+process_one() {
+  local slug="$1"
+  local url="${SPECIMENS_BASE}/${slug}.png"
+  local outfile="$TMPDIR/${slug}.txt"
+
+  DESCRIPTION=$(mindstudio analyze-image \
+    --prompt "$PROMPT" \
+    --image-url "$url" \
+    --output-key analysis \
+    --no-meta 2>&1) || true
+
+  if [ -z "$DESCRIPTION" ] || echo "$DESCRIPTION" | grep -q '"error"'; then
+    echo "    FAILED — $slug"
+    return
+  fi
+
+  echo "$DESCRIPTION" > "$outfile"
+  echo "    OK — $slug"
+}
+
+merge_batch() {
+  python3 -c "
+import json, os
+fonts_file = '$FONTS_FILE'
+tmp_dir = '$TMPDIR'
+with open(fonts_file, 'r') as f:
+    data = json.load(f)
+slug_to_font = {f['slug']: f for f in data['fonts']}
+for filename in os.listdir(tmp_dir):
+    if not filename.endswith('.txt'):
+        continue
+    slug = filename[:-4]
+    if slug in slug_to_font:
+        with open(os.path.join(tmp_dir, filename)) as f:
+            slug_to_font[slug]['description'] = f.read().strip()
+        os.remove(os.path.join(tmp_dir, filename))
+with open(fonts_file, 'w') as f:
+    json.dump(data, f, indent=2)
+    f.write('\n')
+"
+}
+
+# Process in batches of 5
+BATCH=()
+BATCH_COUNT=0
+while IFS= read -r slug; do
+  BATCH+=("$slug")
+  if [ ${#BATCH[@]} -eq 5 ]; then
+    BATCH_COUNT=$((BATCH_COUNT + ${#BATCH[@]}))
+    echo "  Batch $BATCH_COUNT/$REMAINING"
+    for s in "${BATCH[@]}"; do
+      process_one "$s" &
+    done
+    wait
+    merge_batch
+    BATCH=()
+  fi
+done <<< "$SLUGS"
+
+# Process remaining
+if [ ${#BATCH[@]} -gt 0 ]; then
+  BATCH_COUNT=$((BATCH_COUNT + ${#BATCH[@]}))
+  echo "  Batch $BATCH_COUNT/$REMAINING"
+  for s in "${BATCH[@]}"; do
+    process_one "$s" &
+  done
+  wait
+  merge_batch
+fi
+
+rm -rf "$TMPDIR"
+FINAL=$(python3 -c "import json; print(sum(1 for f in json.load(open('$FONTS_FILE'))['fonts'] if f.get('description')))")
+echo "Done. $FINAL/$TOTAL fonts have descriptions."

package/dist/subagents/designExpert/data/compile-inspiration.sh

@@ -15,7 +15,12 @@ SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
 RAW_FILE="$SCRIPT_DIR/inspiration.raw.json"
 OUT_FILE="$SCRIPT_DIR/inspiration.json"
 
-PROMPT="Analyze this website/app screenshot as a design reference. Assess: 1) Mood/aesthetic 2) Color palette with approximate hex values and palette strategy 3) Typography style 4) Layout composition (symmetric/asymmetric, grid structure, whitespace usage, content density) 5) What makes it distinctive and interesting vs generic AI-generated interfaces. Be specific and concise."
+PROMPT_FILE="$SCRIPT_DIR/../prompts/tool-prompts/design-analysis.md"
+if [ ! -f "$PROMPT_FILE" ]; then
+  echo "Error: $PROMPT_FILE not found"
+  exit 1
+fi
+PROMPT=$(cat "$PROMPT_FILE")
 
 if [ ! -f "$RAW_FILE" ]; then
   echo "Error: $RAW_FILE not found"