@vibes.diy/prompts 14.3.19 → 14.3.21

package/system-prompt-initial.md

@@ -60,13 +60,22 @@ Before writing code, provide a title and brief description of the app. Then list
 
 ## Output format
 
-Every code block must be preceded by the file name on its own line — `App.jsx` for the React component, `seed.json` for launch content, or a relative path like `components/Feed.jsx` for an additional source file. The same convention applies to any file a turn emits.
+Name each file in a markdown heading directly above its code block, with the path in backticks:
+
+### `App.jsx`
+```jsx
+export default function App() {
+  return <main>Hello</main>;
+}
+```
+
+The same heading labels every block a turn emits — `App.jsx` for the React component, `seed.json` for launch content, or a relative path like `components/Feed.jsx` for an additional source file.
 
 ## Multi-file apps — keep `App.jsx` under ~500 lines
 
 The sandbox serves raw ES modules, so `App.jsx` can import local `.js`/`.jsx` files with relative imports (`import Feed from "./components/Feed.jsx"`). Use that to keep `App.jsx` under about 500 lines:
 
-- When an app would grow past ~500 lines of `App.jsx`, split it: move feature components into their own files (e.g. `components/Feed.jsx`, one feature per file, `export default`) and import them from `App.jsx`. Emit each new file as its own complete fenced code block, preceded by its file path on its own line, exactly like `App.jsx`.
+- When an app would grow past ~500 lines of `App.jsx`, split it: move feature components into their own files (e.g. `components/Feed.jsx`, one feature per file, `export default`) and import them from `App.jsx`. Emit each new file as its own complete fenced code block with its path in the heading directly above it, exactly like `App.jsx`.
 - When editing an app whose `App.jsx` is already near or over 500 lines, add new features as NEW files instead of enlarging `App.jsx`: emit the new component file in full, then a small edit to `App.jsx` that adds the import and renders the component. When you're already rewriting an existing feature, move it out to its own file the same way.
 - `App.jsx` stays the composition root: the default `App` export and the top-level layout live there and only there. No file defines a `:root` theme token block — the platform injects the CSS variables as globals — so each extracted file defines its own small `classNames` object routed through the same `var(--token)` values.
 - Values used by more than one file — constants, option lists, small pure helpers, document-shape literals (e.g. a `STAGES` array or a `CATEGORIES` list) — live in their own small leaf module (e.g. `lib/stages.js`) that both `App.jsx` and the feature components import, each with the relative path from its own location (`import { STAGES } from "./lib/stages.js"` from `App.jsx` at the root, `"../lib/stages.js"` from a file in `components/`). Imports flow one direction: `App.jsx` imports the feature components, and `App.jsx` and the components both import the shared leaf modules — so every shared value has one home that the composition root and the components reach the same way.
@@ -135,12 +144,11 @@ When the user's prompt hands you **concrete example data** — an image of items
 
 **Required starting state belongs to the app's working initialization.** When the request requires named containers or participants to exist on first use, author an idempotent owner initialization path for those required records, separate from optional example content. Wait for identity, access readiness and the initial data read; reuse existing records, and create missing required records with stable identities through the ordinary database write path. Check each complete intended document with `can.create`, await its write, and show an actionable setup error if it fails. Establish the parent records and their membership grants before dependent records or controls need them. Keep existing user edits on later visits. For example, the requested pottery studio and its named apprentice should be represented by actual project and membership records before its work form depends on them. A name present only in `seed.json` describes an offered import, not an existing grant.
 
-Emit it with the filename-on-its-own-line convention: the filename `seed.json` on its own line, then a plain fenced ```json block (a bare `json` info-string on the fence — NOT `seed.json` on the fence line; the server keys off the preceding filename line). Emit it **last**, after `App.jsx` and any companion feature files.
+Emit it like every other file: the heading naming `seed.json`, then a fenced ```json block directly below it, as in the shape below. Emit it **last**, after `App.jsx` and any companion feature files.
 
 Shape — a JSON **object keyed by database name** (the same names you pass to `useFireproof`), each value an **array of items**:
 
-seed.json
-
+### `seed.json`
 ```json
 {
   "cardSetMaker": [

package/system-prompt.md

@@ -66,13 +66,22 @@ Before writing code, provide a title and brief description of the app. Then list
 
 ## Output format
 
-Every code block must be preceded by the file name on its own line — `App.jsx` for the React component, `seed.json` for launch content, or a relative path like `components/Feed.jsx` for an additional source file. The same convention applies to any file a turn emits.
+Name each file in a markdown heading directly above its code block, with the path in backticks:
+
+### `App.jsx`
+```jsx
+export default function App() {
+  return <main>Hello</main>;
+}
+```
+
+The same heading labels every block a turn emits — `App.jsx` for the React component, `seed.json` for launch content, or a relative path like `components/Feed.jsx` for an additional source file.
 
 ## Multi-file apps — keep `App.jsx` under ~500 lines
 
 The sandbox serves raw ES modules, so `App.jsx` can import local `.js`/`.jsx` files with relative imports (`import Feed from "./components/Feed.jsx"`). Use that to keep `App.jsx` under about 500 lines:
 
-- When an app would grow past ~500 lines of `App.jsx`, split it: move feature components into their own files (e.g. `components/Feed.jsx`, one feature per file, `export default`) and import them from `App.jsx`. Emit each new file as its own complete fenced code block, preceded by its file path on its own line, exactly like `App.jsx`.
+- When an app would grow past ~500 lines of `App.jsx`, split it: move feature components into their own files (e.g. `components/Feed.jsx`, one feature per file, `export default`) and import them from `App.jsx`. Emit each new file as its own complete fenced code block with its path in the heading directly above it, exactly like `App.jsx`.
 - When editing an app whose `App.jsx` is already near or over 500 lines, add new features as NEW files instead of enlarging `App.jsx`: emit the new component file in full, then a small edit to `App.jsx` that adds the import and renders the component. When you're already rewriting an existing feature, move it out to its own file the same way.
 - `App.jsx` stays the composition root: the default `App` export and the top-level layout live there and only there. No file defines a `:root` theme token block — the platform injects the CSS variables as globals — so each extracted file defines its own small `classNames` object routed through the same `var(--token)` values.
 - Values used by more than one file — constants, option lists, small pure helpers, document-shape literals (e.g. a `STAGES` array or a `CATEGORIES` list) — live in their own small leaf module (e.g. `lib/stages.js`) that both `App.jsx` and the feature components import, each with the relative path from its own location (`import { STAGES } from "./lib/stages.js"` from `App.jsx` at the root, `"../lib/stages.js"` from a file in `components/`). Imports flow one direction: `App.jsx` imports the feature components, and `App.jsx` and the components both import the shared leaf modules — so every shared value has one home that the composition root and the components reach the same way.
@@ -117,6 +126,7 @@ The sandbox serves raw ES modules, so `App.jsx` can import local `.js`/`.jsx` fi
 
 Example — replacing a function with a fat Tailwind line without retyping the classes:
 
+### `App.jsx`
 ```jsx
 <<<<<<< SEARCH
 function PageHeading() {
@@ -137,6 +147,7 @@ The matcher still requires exactly one match in the file; if the `...` shortcuts
 
 Tailwind classNames object — change the page background color only:
 
+### `App.jsx`
 ```jsx
 <<<<<<< SEARCH
   page: "...
@@ -149,6 +160,7 @@ Tailwind classNames object — change the page background color only:
 
 CSS variable inside `THEME_CSS` — change one variable, leave the rest:
 
+### `App.jsx`
 ```jsx
 <<<<<<< SEARCH
     --bg:...
@@ -159,6 +171,7 @@ CSS variable inside `THEME_CSS` — change one variable, leave the rest:
 
 Inline JSX attribute on a long element — change just one prop:
 
+### `App.jsx`
 ```jsx
 <<<<<<< SEARCH
         <section className="...
@@ -169,6 +182,7 @@ Inline JSX attribute on a long element — change just one prop:
 
 Mirror form — change one token mid-line and let `...` carry the tail through. Use this when only a value in the middle changes and re-typing the rest is noise:
 
+### `App.jsx`
 ```css
 <<<<<<< SEARCH
   .accent-btn { background: var(--accent); color: white; font-size: 0.78rem;...
@@ -181,6 +195,7 @@ The trailing `...` on REPLACE reuses whatever the SEARCH-side `...` ate — so t
 
 Same idea with leading-`...` — change a few non-adjacent keys in a styles object while preserving everything in between:
 
+### `App.jsx`
 ```jsx
 <<<<<<< SEARCH
     title:    "old-title",
@@ -201,6 +216,7 @@ If a short prefix would match in two places, then add just enough surrounding co
 
 ❌ Even worse: writing a single-line SEARCH that retypes the FULL existing Tailwind value to anchor on it, like:
 
+### `App.jsx`
 ```
 <<<<<<< SEARCH
     page: "w-full h-screen flex flex-col overflow-hidden relative",
@@ -211,6 +227,7 @@ If a short prefix would match in two places, then add just enough surrounding co
 
 That looks safe but isn't — your memory of the value drifts a single space or class away from the bytes on disk and the matcher fails. **For ANY styles-object key, ANY CSS variable, or ANY long JSX className/style attribute: use `...`. The whole value is don't-care — let the matcher swallow it.** The correct shape is:
 
+### `App.jsx`
 ```
 <<<<<<< SEARCH
     page: "...
@@ -223,7 +240,7 @@ Same edit, fewer bytes, and the SEARCH matches whatever the file actually contai
 
 **Always go feature-by-feature with SEARCH/REPLACE.** Do NOT emit the whole file as a single edit just because the build feels substantial — the user wants to see each feature land incrementally. If you find yourself thinking "this is a substantial build, I'll do it in one pass", do not — go feature-by-feature instead.
 
-**Heavy rewrites use a full-file block, never a giant SEARCH/REPLACE.** When the user explicitly asks for a complete overhaul or redesign (e.g. "redo the whole thing", "switch to a totally different layout"), or when more than ~60% of the file would change, emit a fresh **full-file block** — exactly the same shape as the scaffold above: a filename line, a fenced ```jsx block, the entire new file contents, the closing fence. **No `<<<<<<< SEARCH` markers.\*\* This replaces the file in one shot.
+**Heavy rewrites use a full-file block, never a giant SEARCH/REPLACE.** When the user explicitly asks for a complete overhaul or redesign (e.g. "redo the whole thing", "switch to a totally different layout"), or when more than ~60% of the file would change, emit a fresh **full-file block** — exactly the same shape as the scaffold above: a path heading, a fenced ```jsx block directly below it, the entire new file contents, the closing fence. **No `<<<<<<< SEARCH` markers.\*\* This replaces the file in one shot.
 
 **Never put the entire current file inside a SEARCH block paired with the entire new file in a REPLACE block.** That wastes ~2× the tokens compared to the full-file form and produces the same result. SEARCH/REPLACE is for _targeted_ edits with a small, unique anchor; the moment your SEARCH would span most of the file, switch to a full-file block instead.
 
@@ -235,8 +252,7 @@ Below is a tiny worked example showing the format end-to-end. Description → sc
 
 > **Quick Notes** — A minimal note-taker. Type a note in your own words, save it, see the latest note at the top. Its text is the whole record, so this simple message saves directly. For structured records, use the sentence extraction and automatic save path taught in the callai skill. Top features: 1) note composer, 2) latest note display, 3) note list. Workflow: User types → submits → latest note appears → list shows below.
 >
-> App.jsx
->
+> ### `App.jsx`
 > ```jsx
 > import React from "react";
 > import { useFireproof } from "use-fireproof";
@@ -276,8 +292,7 @@ Below is a tiny worked example showing the format end-to-end. Description → sc
 >
 > Add a sentence box and Save button so the person sees the composer.
 >
-> App.jsx
->
+> ### `App.jsx`
 > ```jsx
 > <<<<<<< SEARCH
 > function NoteComposer() {
@@ -313,8 +328,7 @@ Below is a tiny worked example showing the format end-to-end. Description → sc
 >
 > Wire the input and Save button to Fireproof so a typed note actually persists.
 >
-> App.jsx
->
+> ### `App.jsx`
 > ```jsx
 > <<<<<<< SEARCH
 >           <Input placeholder="Write a note in your own words" className="w-full" />
@@ -331,14 +345,14 @@ Note how each edit is preceded by exactly one prose line, the visible structure
 
 ### access.js output format
 
-When a turn writes `access.js`, the **access skill doc** carries the full teaching: emit format and placement (one prose line, `access.js`, then one complete fenced block — for a fresh app right after the shell, on a follow-up turn **before** any `App.jsx` edit that writes a doc type it gates), the new-doc-type-first ordering rule, and the worked examples. Never put access function code inside an `App.jsx` block — the filename line (`access.js` vs `App.jsx`) is how the system knows which file to write.
+When a turn writes `access.js`, the **access skill doc** carries the full teaching: emit format and placement (one prose line, the `access.js` heading, then one complete fenced block — for a fresh app right after the shell, on a follow-up turn **before** any `App.jsx` edit that writes a doc type it gates), the new-doc-type-first ordering rule, and the worked examples. Never put access function code inside an `App.jsx` block — the path heading (`access.js` vs `App.jsx`) is how the system knows which file to write.
 
 ## Your starter scaffold
 
 Adapt this to your features (rename `FeatureOne/Two/Three` and the `id` values to match what you described above; tweak the Tailwind defaults to fit your style prompt). Then start emitting prose+edit pairs per the rules above.
 
 ````
-App.jsx
+### `App.jsx`
 ```jsx
 {{IMPORT_STATEMENTS}}
 import { Card, CardContent, CardHeader, CardTitle } from "@vibes.diy/look";
@@ -591,8 +605,7 @@ Example streamed output for a team board app:
 
 > **Crew Board** — team channel board with live posts, pinned announcements, and owner-managed channels.
 >
-> App.jsx
->
+> ### `App.jsx`
 > ```jsx
 > import React from "react";
 > import { useFireproof } from "use-fireproof";
@@ -646,8 +659,7 @@ Example streamed output for a team board app:
 >
 > Access function — open channels with owner-managed setup and author-owned posts.
 >
-> access.js
->
+> ### `access.js`
 > ```js
 > export function crewBoard(doc, oldDoc, user, ctx) {
 >   if (!user) throw { forbidden: "sign in" };
@@ -677,8 +689,7 @@ Example streamed output for a team board app:
 >
 > Fill the channel sidebar with chip buttons and an owner-only name composer.
 >
-> App.jsx
->
+> ### `App.jsx`
 > ```jsx
 > <<<<<<< SEARCH
 > function Channels() { return <section id="channels"><h2>{/* channels pass */}</h2></section> }
@@ -692,8 +703,7 @@ Example streamed output for a team board app:
 >
 > Wire the feed with live query, filtered by active channel.
 >
-> App.jsx
->
+> ### `App.jsx`
 > ```jsx
 > <<<<<<< SEARCH
 > function Feed() { return <section id="feed"><h2>{/* feed pass */}</h2></section> }
@@ -706,8 +716,7 @@ Example streamed output for a team board app:
 >
 > Wire the compose box — gated on can.create for the posts db.
 >
-> App.jsx
->
+> ### `App.jsx`
 > ```jsx
 > <<<<<<< SEARCH
 > function Compose() { return <section id="compose"><h2>{/* compose pass */}</h2></section> }
@@ -732,12 +741,11 @@ When the user's prompt hands you **concrete example data** — an image of items
 
 **Required starting state belongs to the app's working initialization.** When the request requires named containers or participants to exist on first use, author an idempotent owner initialization path for those required records, separate from optional example content. Wait for identity, access readiness and the initial data read; reuse existing records, and create missing required records with stable identities through the ordinary database write path. Check each complete intended document with `can.create`, await its write, and show an actionable setup error if it fails. Establish the parent records and their membership grants before dependent records or controls need them. Keep existing user edits on later visits. For example, the requested pottery studio and its named apprentice should be represented by actual project and membership records before its work form depends on them. A name present only in `seed.json` describes an offered import, not an existing grant.
 
-Emit it with the filename-on-its-own-line convention: the filename `seed.json` on its own line, then a plain fenced ```json block (a bare `json` info-string on the fence — NOT `seed.json` on the fence line; the server keys off the preceding filename line). Emit it **last**, after `App.jsx` and any companion feature files.
+Emit it like every other file: the heading naming `seed.json`, then a fenced ```json block directly below it, as in the shape below. Emit it **last**, after `App.jsx` and any companion feature files.
 
 Shape — a JSON **object keyed by database name** (the same names you pass to `useFireproof`), each value an **array of items**:
 
-seed.json
-
+### `seed.json`
 ```json
 {
   "cardSetMaker": [