@genex-ai/cli-demo 0.48.0-dev.79 → 0.48.0-dev.86

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@genex-ai/cli-demo",
-  "version": "0.48.0-dev.79",
+  "version": "0.48.0-dev.86",
   "description": "Set up your ~/.claude workspace, authorize, create a game project, generate AI assets, and publish (genex CLI).",
   "type": "module",
   "bin": {

package/templates/skills/genex-ai-hud/SKILL.md

@@ -28,15 +28,19 @@ ring) that no hand-written CSS can fake.
   the CSS placeholder, finished to `$genex-threejs-game-ui`'s Tier-1 floor,
   ships as the HUD.
 
-## Three layers — glass is CSS, chrome is sprites, data is DOM
-
-- **Glass (DOM).** The translucent plate behind every widget is CSS —
-  `background: rgba(<brief's darkest hue>, 0.35–0.6)` plus
-  `backdrop-filter: blur(6–12px)` (and its `-webkit-` twin). Semi-transparency
-  physically cannot survive sprite extraction: a composited panel's pixels are
-  a blend of panel and background, and no cutout can un-blend them — so glass
-  is NEVER baked into a sprite. This is how AAA smoked-glass HUDs are built:
-  live glass panels, crisp art on top.
+## Three layers — plates are DOM, chrome is sprites, data is DOM
+
+- **Plate (DOM).** The backing surface behind a widget is built in CSS — in
+  whatever register the brief and concept frame call for: smoked glass
+  (`background: rgba(<darkest hue>, 0.35–0.6)` + `backdrop-filter: blur(6–12px)`
+  and its `-webkit-` twin) when the style wants translucency, a solid painted
+  plate, a subtle gradient — or no plate at all for an outline-led look.
+  **Glass is a technique, not a default** — do not reach for translucency
+  because this skill mentions it; reach for it when THIS game's brief does.
+  What is fixed is WHERE plates are built — the DOM — because
+  semi-transparency physically cannot survive sprite extraction: a composited
+  panel's pixels are a blend of panel and background, and no cutout can
+  un-blend them. Plates are NEVER baked into sprites.
 - **Chrome (sprites — what THIS pipeline generates).** Opaque frames, corner
   brackets, ornaments, emblems, icons, medallions — hard-alpha art laid over
   the glass. The Stage-2 sheet contains ONLY chrome; never a panel with its
@@ -60,10 +64,11 @@ The HUD overlays a **live 3D scene**. The pixels between widgets show the game.
   fabric, wood board) as part of the HUD. Material aesthetics belong on the
   widget FRAMES — the HP bar frame is parchment, the minimap ring is leather —
   never on a screen-filling sprite.
-- **No glass in sprites.** Translucent panel plates in the mockup are welcome
-  as the LOOK, but the Stage-2 asset list requests only their opaque chrome
-  (frame, brackets, ornament); the plate itself is rebuilt at runtime as CSS
-  glass matching the mockup's tint (see the three layers above).
+- **No plates in sprites.** Panel plates in the mockup — translucent or
+  solid — are welcome as the LOOK, but the Stage-2 asset list requests only
+  their opaque chrome (frame, brackets, ornament); the plate itself is
+  rebuilt at runtime in CSS matching the mockup's tint (see the three layers
+  above).
 - **4–7 widgets.** Fewer doesn't read as a HUD; more clutters the screen and
   burns generations.
 - **Every widget needs internal contrast** — a panel fill, outline stroke, or
@@ -123,7 +128,10 @@ scaffolding, plain-CSS placeholder bars) while it renders — the CSS HUD keeps
 the game playable until the sprites land. When the gate produced a concept
 frame, anchor Stage 1 to it — `--edit <concept-url>` holds the game's
 register far better than a text-only prompt; single-sprite regenerations
-anchor the same way. Generate 2 mockup candidates in one
+anchor the same way. The concept is a STYLE anchor only: the widget set and
+layout come from the element inventory and the game contract — a mechanic
+the concept invented (a lap counter, a stamina orb) does not enter the HUD,
+and a mechanic it failed to show still does. Generate 2 mockup candidates in one
 call (`--candidates 2`) and pick the better one: a re-roll costs the whole
 serial chain, a second candidate costs nothing extra in wall-clock.
 

package/templates/skills/genex-ai-hud/references/stage2-prompt-template.md

@@ -15,10 +15,10 @@ Fill `[ASSET_LIST]`, then pass the whole text as the prompt to
   identity labels);
 - **states what to REMOVE** (`runtime_static` labels and `runtime_dynamic`
   values, fills, items);
-- **requests chrome only** — never a panel's translucent plate or glass
-  surface: plates are rebuilt at runtime as CSS glass (rgba +
-  backdrop-filter), so ask for the panel's frame/brackets/ornament, not the
-  panel surface itself;
+- **requests chrome only** — never a panel's plate/backing surface,
+  translucent or solid: plates are rebuilt at runtime in CSS (rgba,
+  backdrop-filter, or a solid fill — whatever matches the mockup), so ask
+  for the panel's frame/brackets/ornament, not the panel surface itself;
 - **requests the annotated duplicate** for every bar/meter frame (the
   template's progress block below covers the mechanics — your item just says
   "output the clean frame + annotated duplicate pair").

package/templates/skills/genex-threejs-game-ui/SKILL.md

@@ -68,12 +68,32 @@ you're borrowing. The bar is what those games ship, not "good enough for a
 demo". Conventions only — never logos, exact layouts, or trade dress. The
 same 2–3 names carry into the router's visual-direction gate for the scene.
 Then turn references + brief into ONE **concept frame** — a single generated
-image of what THIS game should look like mid-play (scene, mood, lighting;
-a UI impression is welcome but optional):
-`npx genex image "<one-sentence game look from the brief>" --aspect 16:9 --quality high --no-wait`,
-enqueued FIRST of all art. Its URL goes into the style-brief comment as the
-game's north star: every later 2D generation that accepts `--edit` anchors
-to it, and the scene's lighting/grading is judged against it.
+image of a PLAYABLE MOMENT of this game, not key art. Build the prompt from
+the game contract, not just the mood: what the player is DOING mid-action
+(the verb), what threatens them right now (enemy silhouettes), what they
+are chasing (the objective — a finish gate, a goal, a pickup), and how the
+space reads (route, scale) — plus the brief's palette, materials, and
+light. A beautiful empty vista with nothing to fight and nowhere to go is a
+FAILED concept; so is one that invents mechanics the game doesn't have (a
+lap counter in a game without laps). `--aspect 16:9 --quality high
+--no-wait`, enqueued FIRST of all art; the URL goes into the style-brief
+comment.
+
+**Share it before building on it.** The moment the frame lands, show it to
+the user — "this is roughly how the game will look: keep it, or change
+something?" — as ONE structured question with 2–3 concrete adjustment
+options. Keep building gameplay-neutral work (scaffold, physics, netcode)
+while waiting, but do NOT anchor further art to an unapproved frame; if the
+user redirects, regenerate with their notes before the HUD mockup and menu
+frame go out.
+
+**The concept anchors STYLE, not truth.** Palette, materials, light, and
+register come from the frame; CONTENT comes from the game contract. When
+the frame lands, diff it against the contract in one visible line — what
+does this game have that the frame doesn't show (enemies? arenas? the
+finish? the pickup)? Carry those requirements in words into every later
+prompt. Where the frame contradicts gameplay, gameplay wins — never inherit
+an invented mechanic, or the absence of a real one, from a picture.
 
 **4. Ask only when genuinely ambiguous.** If the concept pins the mood (a
 "gothic horror dungeon crawler" pins it), decide and state the plan in one

package/templates/skills/genex-threejs-skill-router/references/routing-map.md

@@ -25,8 +25,10 @@ Three.js release or branch, and do not blindly copy demo architecture.
    decided silently. Enqueue the Tier-2 UI generations now with `--no-wait`
    (pick them up later with `npx genex wait <id>`) — they render server-side
    while you build the game. FIRST of all art: the gate's **concept frame** —
-   the single image of the finished game's look that every later `--edit`-able
-   generation anchors to. Then the `$genex-ai-hud` Stage-1 mockup, enqueued
+   a playable-moment shot (verb + threat + objective in frame, per the
+   game-ui gate), shown to the user for a keep-or-change answer the moment
+   it lands; later `--edit`-able generations anchor to it for STYLE while
+   the game contract owns content. Then the `$genex-ai-hud` Stage-1 mockup, enqueued
    here for EVERY game; and the `$genex-ai-menu` video whenever the menu
    decision is yes (the default for every game — "it's only a draft" is not a
    reason to decide no). Skipping this enqueue is
@@ -50,8 +52,8 @@ Three.js release or branch, and do not blindly copy demo architecture.
    - **references**: name 2–3 AAA games whose look this game borrows
      (conventions, lighting mood, palette, post — never trade dress); the
      same 2–3 the UI gate named, extended from the interface to the scene,
-     and embodied in the gate's concept frame — the image the scene is
-     judged against;
+     and embodied in the gate's concept frame — the image the scene's STYLE
+     is judged against (content always comes from the game contract);
    - **ambient motion**: name ONE subtle environmental motion loop that keeps
      the scene alive at rest — an emissive pulse along edges, heat shimmer,
      drifting dust, a slowly flowing texture. Shader/procedural, zero
@@ -110,6 +112,33 @@ Three.js release or branch, and do not blindly copy demo architecture.
 13. Validate in a real browser with fixed seeds, captures, interaction checks,
     and performance evidence.
 
+## Parallelize with subagents (when the environment has them)
+
+Generations already render server-side in parallel — the wall-clock savings
+live in the ATTENDED chains. When the coding agent supports background
+subagents (e.g. Claude Code's Agent tool), split these off; in environments
+without them (Cursor), the same order simply runs sequentially and the
+`--no-wait` pattern still hides most generation latency.
+
+- **HUD chain worker.** The moment the Stage-1 mockup lands, hand the whole
+  `$genex-ai-hud` chain to one subagent: pick the better candidate → Stage-2
+  sheet → clean → extract → masks → write the sprite wiring. Its prompt must
+  be self-contained — the style brief, concept-frame and mockup URLs, the
+  output dir, and exactly which files it owns.
+- **Asset shepherd.** One subagent runs `npx genex wait` on every queued ID
+  and wires each asset in as it lands (skybox, models, menu video, dressing),
+  swapping placeholders out and reporting each swap.
+- **Verification runner.** Browser evidence — screenshots, control presses,
+  the menu loop-seam watch, in-situ checks of placed art — can run in a
+  subagent while the main agent keeps building.
+
+Hard rules: **one writer per file** — each subagent owns a disjoint file set
+(the HUD worker owns the hud modules and `public/assets/hud/`, the shepherd
+owns asset-wiring modules), and the main agent stays the only writer of
+gameplay/netcode. Merge points are explicit: a subagent reports what it
+changed, the main agent reconciles. Never put two writers on the same
+module — a corrupted entry point costs more than the minutes saved.
+
 ## Acceptance gate
 
 **Game fast path:** for a game task that loaded no procedural/visual-system skill,