castle-web-cli 0.4.45 → 0.4.46

package/dist/agent-prompts.js

@@ -113,7 +113,7 @@ export function buildTaskPrompt(opts) {
     const wrapUp = opts.backend === 'claude'
         ? `\n- Wrap up in ONE tool call, not several: once your last file edit is done, combine the 90-progress write, the final \`npm run restart\`, and writing the notes file into a single shell command (\`;\`-separated so the notes land even if the restart hiccups). Then stop -- no extra turns after it.`
         : '';
-    return `You are a background build agent for the Castle deck "${opts.deckLabel}" (current directory). A separate conversation agent dispatched you with one task. Read the deck's CLAUDE.md / AGENTS.md first and follow its workflow (including reloading the served deck after changes, e.g. \`npm run restart\`).
+    return `You are a background build agent for the Castle deck "${opts.deckLabel}" (current directory). A separate conversation agent dispatched you with one task. Follow the deck's CLAUDE.md / AGENTS.md conventions, and reload the served deck after changes (\`npm run restart\`).
 
 Your task (id ${opts.taskId}): ${opts.title}
 
@@ -127,7 +127,7 @@ Operating rules:
 - Other task agents may be editing this same deck IN PARALLEL. When you change an existing file, READ it first and make a targeted edit to just the part you need -- never overwrite a whole file you have not read. A blind full-file rewrite clobbers other agents' in-flight changes. Being a bit slower and careful here is the right tradeoff.
 - Favor real, editable assets: for game objects, characters, and scenery, make drawings (drawings/*.drawing pixel art) and place them as real actors in the scene rather than code-drawn shapes -- it keeps the deck editable in the editor and remixable. (Data-driven UI like health bars, score/text, and HUD gauges, plus dynamic things like bullets/particles/effects, stay procedural -- don't force those into drawings.)
 - Update your progress VERY frequently: write a bare integer 0-100 to ${opts.progressPath} (e.g. \`echo 30 > ${opts.progressPath}\`) every time you advance -- at least every 10 points, or every 20 for properly small tasks. Start near 10, write 90 just before wrapping up. Never let it sit stale while you work.
-- Before finishing, write ${opts.notesPath}: a SHORT test guide for the user -- 2-4 brief sentences. Lead with exactly what to try in the running deck; mention a blocker or open question if you hit one. NO file-by-file implementation detail, no code names unless the user needs them to test. The user reads this verbatim when checking your work off.${wrapUp}
+- Before finishing, write ${opts.notesPath}: a SHORT test guide for the user -- 1-2 sentences (a 3rd only if it really merits). Lead with exactly what to try in the running deck; mention a blocker or open question if you hit one. NO file-by-file implementation detail, no code names unless the user needs them to test. The user reads this verbatim when checking your work off.${wrapUp}
 - If you are truly blocked, write the blocker to the notes file and stop rather than guessing wildly.
 - Never touch files under .castle/ other than those two paths.`;
 }

package/kits/basic-2d/CLAUDE.md

@@ -17,6 +17,7 @@ The deck is already serving when you start (`castle-web init` set that up; see `
 1. **Build incrementally.** Start with the smallest playable thing (one mechanic, one scene change), `npm run restart`, then add the next piece. Do NOT write the whole game in one shot.
 2. **After every edit:** `npm run restart` (no hot reload). The served page refreshes and the user sees the change.
 3. **Prefer real, editable assets.** For game objects, characters, and scenery, make actual drawings (`drawings/*.drawing`) and place them as real actors in `scenes/*.scene` — not shapes drawn in code. Real assets let the creator move and re-skin things in the editor and let other creators remix the deck. Data-driven UI (health bars, score/text, HUD gauges) and dynamic things (bullets, particles, effects) are correctly procedural/code — don't force those into drawings.
+4. **Separate scenes per screen.** Use a separate `scenes/*.scene` file for each distinct screen — menu/title, each level, game-over, etc. — not one mega-scene. Each stays independently editable in the editor. Switch at runtime with `scene.load(targetSceneData)`; wire the transition deck-side (e.g. import the target `.scene` JSON and call `scene.load` on play / win / level change).
 
 Card size is **500 wide × 700 tall** (origin top-left, +y is down).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "castle-web-cli",
-  "version": "0.4.45",
+  "version": "0.4.46",
   "type": "module",
   "bin": {
     "castle-web": "./dist/index.js"