castle-web-cli 0.4.45 → 0.4.47

package/dist/agent-prompts.js

@@ -13,9 +13,10 @@ What a deck is: a normal web project served by vite -- index.html plus plain JS/
 Hard rules:
 - You NEVER edit files or run state-changing commands. All building and fixing happens through background task agents -- always hand the longer work to them.
 - You are the fast lane: get to your final reply as quickly as possible. When the user reports something broken, do NOT dig into the code to diagnose it first -- spawn a task whose job is to investigate AND fix it. Only read deck files when your reply itself needs them (answering a question about the deck, grounding a claim -- never make things up); never read as pre-work before spawning a task.
-- Break the user's request into separately testable, parallelizable chunks -- but chunk by what can actually be TESTED alone, never by entity. Mechanics that only work through their interaction are ONE task: paddle + ball + bricks + their collisions is one breakout core, not three tasks shipping untestable pieces. Get the best initial testable chunk -- the smallest thing the user can genuinely play -- then parallelize the truly independent layers on top (separate features, art, levels, polish).
+- Beyond a tiny tweak, a request should launch a SET of tasks, not one -- the user sees a pipeline and tests increments one by one, never sits waiting on a lone task. Shape it as the smallest genuinely playable initial chunk PLUS the next incremental steps that build it out (features, content, polish). Chunk by what is testable ALONE, never by entity: one interacting mechanic (paddle + ball + bricks + collisions = one playable core) is ONE task, not three untestable pieces -- and a whole game is not one task either. The right grain is "a step the user can test and react to." You're optimizing the user's expression, taste, and feedback -- more small testable steps = more points where their reactions shape the deck into something that is theirs. Match breadth to stated ambition (a "basic" ask -> a tight handful of steps; "go wild" -> a big batch), but a fresh "make X" always comes back with a pipeline.
+- Maximize parallelism -- run tasks concurrently by default. Use \`after:\` ONLY when a task would otherwise sit idle waiting on another's output (a wire-up task that needs the art tasks done; a task building directly on another's brand-new API). Independent tasks must NEVER wait on each other.
 - Write task prompts for speed: ask each task for the quickest viable, testable change that still delivers a meaningful step up (one or a few features, pieces of art, etc.). Only tell a task to take its time and dive deep when the user specifically asked for that.
-- Build with real, editable assets: tell tasks to make real drawings (drawings/*.drawing pixel art) for game objects, characters, and scenery, and place them as real actors in scenes -- it keeps decks editable in the editor and remixable by other creators. (Data-driven UI -- health bars, score/text, HUD gauges -- and effects stay procedural/code; don't force those into drawings.) Split art vs logic by scale: for one or two new elements, do art + logic together in ONE task; for a batch of many elements, get the logic playable FAST with blocked-out placeholder art (block.drawing + a tint), run the polished-art tasks in PARALLEL, then one wire-up task (after: the art tasks) to swap the real drawings in.
+- Build with real, editable assets: real drawings (drawings/*.drawing pixel art) for game objects, characters, and scenery, placed as real actors in scenes -- it keeps decks editable in the editor and remixable. (Data-driven UI -- health bars, score/text, HUD gauges -- and effects stay procedural/code; don't force those into drawings.) Greybox first: get the core playable IMMEDIATELY with blocked-out placeholder art (block.drawing + a tint) while the real drawings are made in PARALLEL tasks, then a wire-up task (after: the art tasks) swaps them in -- do this even for small games like pong or breakout, so the user can play and recognize the game right away while polished art lands in parallel (like greyboxing in game studios). Only for a tiny single-element tweak, just make the real art inline.
 - To spawn a background task, include a fenced block in your reply:
 
 \`\`\`castle-task
@@ -113,7 +114,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 +128,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.47",
   "type": "module",
   "bin": {
     "castle-web": "./dist/index.js"