@genex-ai/cli-demo 0.94.0-dev.251 → 0.95.0-dev.253

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@genex-ai/cli-demo",
-  "version": "0.94.0-dev.251",
+  "version": "0.95.0-dev.253",
   "description": "Set up your project's agent workspace (.claude/.codex/.cursor in the game folder), authorize, create a game project, generate AI assets, and publish (genex CLI).",
   "type": "module",
   "bin": {

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

@@ -14,11 +14,11 @@ exemption; **"no human body ever appears in this game" is.** A game whose
 player is genuinely not a person — a car, a ship, an RTS cursor, a puzzle
 board — generates that object with `npx genex model` instead.
 
-**Start it EARLY** — enqueue the character right after the design interview,
-alongside the Stage-1 HUD concept, not as an afterthought once the world is
-built. Its concept candidates ride the same review beat as the HUD concept, and
-firing at minute 0 means it lands around the v0 preview instead of long after
-it.
+**Start it EARLY** — enqueue the character with your first art actions, not as
+an afterthought once the world is built. It is the player's body and every
+stage of it takes minutes server-side, so firing at minute 0 means it lands
+around the v0 preview instead of long after it. Its concept candidates get
+their own review beat with the player when they arrive.
 
 Until it lands, the player's body is the profile VRM avatar. That is a fallback
 in two shapes and both are spoken aloud: a **temporary** body while the
@@ -38,15 +38,14 @@ no code to rewrite, which is exactly why there is no excuse to skip it.
 **Two lanes, two approval shapes:**
 
 - **The game-default lane (one user stop).** The three concept candidates
-  ride the SAME review beat as the game-concept keep-or-change question —
-  one review, two picks. The player's pick authorizes the whole lane
-  (preview and the 10,000-face rigging remesh both proceed on it — state
-  each step plainly as you run it). If the player hasn't picked by the
-  time the character blocks progress (or ~10 minutes), pick the strongest
-  candidate yourself, say which and why in chat, and proceed. That
-  auto-proceed — including its generation spend — is owner-ratified
-  platform policy (2026-07-23), not an agent liberty: record the pick in
-  DESIGN.md → Decisions.
+  ARE the review beat: show the actual images, the player picks one. That
+  pick authorizes the whole lane (preview and the 10,000-face rigging
+  remesh both proceed on it — state each step plainly as you run it). If
+  the player hasn't picked by the time the character blocks progress (or
+  ~10 minutes), pick the strongest candidate yourself, say which and why
+  in chat, and proceed. That auto-proceed — including its generation
+  spend — is owner-ratified platform policy (2026-07-23), not an agent
+  liberty: record the pick in DESIGN.md → Decisions.
 - **The user-initiated custom-character lane (two stops — the ceremony
   below, in full).** When the user themselves asked for a custom
   character, the approvals ARE the product: an explicit candidate

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

@@ -1,37 +1,44 @@
 ---
 name: genex-ai-hud
-description: Generate a production HUD sprite set — matched frames, masks, and icons in one coherent art style — via the mockup-then-deconstruct pipeline (`npx genex image` + `npx genex ui`), then wire it as a DOM overlay with channel-accurate masked fills. Use for EVERY game, kicked off at `genex-threejs-game-ui`'s "Plan the UI first" gate: the sprite HUD is the production HUD of a Genex game; hand-written CSS is only the placeholder while the sprites render.
+description: Generate HUD sprites — matched frames, masks, and icons in one coherent art style — via the mockup-then-deconstruct pipeline (`npx genex image` + `npx genex ui`), then wire them as a DOM overlay with channel-accurate masked fills. Use when the game's own style wants drawn chrome — ornate, painterly, comic, hand-made — when the player asks for HUD art, or to generate one element the game needs.
 ---
 
 # Genex AI · HUD
 
-Generate every sprite of a game HUD in ONE art style — a full-HUD mockup, then
-a deconstruction into individual assets — and wire them as a plain-DOM overlay
+Generate a game's HUD sprites in ONE art style — a full-HUD mockup, then a
+deconstruction into individual assets — and wire them as a plain-DOM overlay
 with masked fills that track the art's real channels. The result is an
 art-directed HUD (etched steel ammo strip, parchment HP bar, chrome minimap
 ring) that no hand-written CSS can fake.
 
-## This is the default HUD — hand-coded CSS is the placeholder
-
-- **Every game runs this pipeline.** Kick the Stage-1 mockup off at
-  `$genex-threejs-game-ui`'s "Plan the UI first" gate (`--no-wait`) and build
-  against that skill's plain-CSS placeholder while it renders — that skill
-  also owns the overlay architecture this one plugs into. The game is not
-  done until the sprites have landed and been wired in.
-- The art direction comes from the shared style brief — gothic filigree
-  frames, rusted post-apocalyptic panels, carbon-fiber racing telemetry,
-  hand-painted storybook plates, or a restrained modern register for a clean
-  concept; restrained still means built from the generated set. ~10 image
-  generations is the normal price of a production HUD, not a premium to
-  justify.
-- **The only exit:** the user explicitly declines the generated HUD — then
-  the CSS placeholder, finished to `$genex-threejs-game-ui`'s Tier-1 floor,
-  ships as the HUD.
+## When to reach for this — and when clean CSS is the answer
+
+- **Drawn chrome earns its place in a game whose own style wants it** —
+  ornate, painterly, comic, hand-made, diegetic. Gothic filigree frames,
+  rusted post-apocalyptic panels, carbon-fiber racing telemetry, hand-painted
+  storybook plates: art the brief already promises and CSS cannot fake. The
+  player asking for HUD art is the same signal, stated out loud.
+- **A restrained interface built in clean CSS is a finished HUD.** For a
+  spare modern game — thin strokes, quiet type, one accent hue — hand-built
+  chrome styled FROM THE BRIEF is the better answer, and it ships as the HUD
+  with nothing owed. It is not scaffolding and not a lesser tier. When you
+  can't tell which way a game leans, lean minimal.
+- **One element is a normal run of this lane.** Generating a single frame,
+  mask, icon, emblem, or wordmark you decided the game needs is first-class
+  use — fill the templates for that one asset (or regenerate it per-sprite,
+  below) and wire it to the same standard. There is no all-or-nothing
+  pipeline to finish.
+- **Whatever you do generate is executed in full.** Extraction, masks,
+  channel-accurate fills, `npx genex ui audit` — judgment decides whether art
+  is generated, never how well it is done. Half-wired sprites are the one
+  outcome this skill has no room for.
+- `$genex-threejs-game-ui` owns the overlay architecture, the shared style
+  brief, and the CSS craft floor this lane plugs into — read it either way.
 
 ## 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 mockup call for: smoked glass
+  whatever register the brief and the mockup 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.
@@ -146,9 +153,9 @@ The HUD overlays a **live 3D scene**. The pixels between widgets show the game.
 
 ## Style brief
 
-Start from the game's ONE shared style brief (`$genex-threejs-game-ui`'s "Plan
-the UI first" gate) — the HUD, menu, and loader consume the same brief; a HUD
-styled in a second world is a bug. Expand it here with what sprites need:
+Start from the game's ONE shared style brief (`$genex-threejs-game-ui` owns
+it) — the HUD, menu, and loader consume the same brief; a HUD styled in a
+second world is a bug. Expand it here with what sprites need:
 materials, an explicit palette of **4–5 named hues**, weathering, line
 treatment, atmosphere. Keep outline stroke width
 consistent across widgets — per-widget stroke changes read as amateur fastest.
@@ -219,10 +226,10 @@ are committing to build):
   grenade slot on a rifle-only HUD, an armor bar with no armor, a minimap over
   no map — is a failure, and "the model drew it so I kept it" is how it happens.
 
-The mockup — which IS the game concept — anchors STYLE; the game contract owns
-WHAT EXISTS. When the picture and the mechanics disagree, the mechanics win.
-Cut widgets are recorded in the UI plan message as "deferred from mockup"
-(`$genex-threejs-game-ui`) — never silently wired, never silently dropped.
+The mockup anchors STYLE; the game contract owns WHAT EXISTS. When the picture
+and the mechanics disagree, the mechanics win. Record a cut widget in
+DESIGN.md as "deferred from mockup" while the lane is running — never silently
+wired, never silently dropped.
 
 ## The pipeline
 
@@ -232,47 +239,40 @@ printed. Fill the two prompt templates —
 and [references/stage2-prompt-template.md](references/stage2-prompt-template.md)
 — before Stages 1 and 2.
 
-**Order of work: kick Stage 1 off as your FIRST action at the UI plan
-gate — the Stage-1 mockup IS the game concept.** There is no separate
-UI-free concept image before it: this ONE generation (no candidate variants
-unless the player asks) carries scene + HUD, serves as the user's style
-checkpoint, and anchors all later art (`$genex-threejs-game-ui` owns the
-checkpoint choreography). **The moment the mockup lands, enqueue Stage 2 +
-the menu still + the logotype `--no-wait` IMMEDIATELY — THEN show the
-player the frame and ask keep/change as information, never as a gate.**
-Silence = the concept stands; a "change" answer loops the concept with the
-player's notes and the chain re-runs from the new frame — image-priced,
-cheap by design, so say so in one line and do it. Only the menu VIDEO waits
-(`$genex-ai-menu` owns its event triple). The scene half
-of the prompt is written in TEXT from the game plan — `[GAME_SCENE]` in the
-Stage-1 template: setting, the moment, what the player is doing, lighting.
-**If a concept/reference image already exists — the user's own concept art, or
-a look frame you generated and they approved — anchor Stage 1 to it with
+**Order of work.** When you have decided this game's HUD gets sprites, Stage 1
+renders a mockup of THIS game's HUD over THIS game's scene — ONE generation,
+no candidate variants unless the player asks. The scene half of the prompt is
+written in TEXT from the game plan — `[GAME_SCENE]` in the Stage-1 template:
+setting, the moment, what the player is doing, lighting. Enqueue it
+`--no-wait` and keep building; kick Stage 2 off as soon as the mockup lands,
+since every sprite is cut from it.
+**If a reference image already exists — the user's own art, or a look frame
+you generated and they approved — anchor Stage 1 to it with
 `--edit <that-url-or-file>` so the HUD inherits its exact palette, materials,
-and lighting; that anchoring is what makes the final HUD actually match the
-concept, and skipping it is why a text-only mockup drifts.** A text-only
-Stage 1 is the fallback for when no reference exists. A user-supplied
-reference needs no upload step: `--edit` takes a local file path directly
-(`--edit ./reference.png`, ≤4 MB inlined) — a chat attachment saved to disk
-is a perfectly good anchor, and "I can't feed the local screenshot into the
-art chain" is never true and never a reason to reach for another tool.
-Then write the
-widget layout and wiring code (placement, masked-fill scaffolding,
-plain-CSS placeholder bars) while it renders — the CSS HUD keeps
-the game playable until the sprites land. When a sprite lands it REPLACES
-its placeholder: delete the placeholder's own background/plate as you wire
-the opaque frame in — a placeholder dark div left behind an opaque sprite
-is the black-box defect. The mockup is a STYLE anchor
-only: the widget set and
-layout come from the element inventory and the game contract — a mechanic
-the mockup invented (a lap counter, a stamina orb) does not enter the HUD,
-and a mechanic it failed to show still does.
+and lighting; that anchoring is what makes the final HUD match the art it is
+supposed to match, and skipping it is why a text-only mockup drifts.** A
+text-only Stage 1 is the normal path when no reference exists. A
+user-supplied reference needs no upload step: `--edit` takes a local file
+path directly (`--edit ./reference.png`, ≤4 MB inlined) — a chat attachment
+saved to disk is a perfectly good anchor, and "I can't feed the local
+screenshot into the art chain" is never true and never a reason to reach for
+another tool. While the mockup renders, write the widget layout and wiring
+code (placement, masked-fill scaffolding, plain-CSS bars) — the game stays
+playable the whole time. When a sprite lands it REPLACES its CSS stand-in:
+delete the stand-in's own background/plate as you wire the opaque frame in —
+a dark div left behind an opaque sprite is the black-box defect. The mockup
+is a STYLE anchor only: the widget set and layout come from the element
+inventory and the game contract — a mechanic the mockup invented (a lap
+counter, a stamina orb) does not enter the HUD, and a mechanic it failed to
+show still does. **A single element needs no mockup at all**: generate it
+straight in the house style (Sprite iteration below), extract it, and wire it
+to the same standard.
 
 ```bash
-# Stage 1 — the game CONCEPT: full HUD composited over the game's own scene.
-# TEXT-described; add `--edit <concept-url-or-local-file>` to anchor it to an
-# existing concept/reference image so the HUD inherits its exact style.
-# ONE concept image; save its URL:
+# Stage 1 — the HUD mockup: this game's full HUD over its own scene.
+# TEXT-described; add `--edit <url-or-local-file>` to anchor it to an
+# existing reference image so the HUD inherits its exact style.
+# ONE mockup; save its URL:
 npx genex image "<filled stage-1 prompt>" --size 2560x1440 --quality high
 
 # Stage 2 — deconstruct the mockup into an asset sheet on white:
@@ -619,27 +619,26 @@ survive paraphrase; the canonical version of this failure is a subagent
 reporting "masks validated" while the parent ships width% fills.
 
 **Do not fire-and-forget the whole HUD/menu/logo into one background subagent.**
-The field failure: the entire production art pipeline was handed to a single
-background agent that then stalled overnight, so every preview the user played
-showed the CSS placeholder and the real HUD only landed hours later, unseen. If
-art runs in a subagent it is a BOUNDED task you wait on, then wire and verify in
-THIS session — not an overnight handoff. While the art is pending the HUD is
-unverified: do not call the game done or push it as a finished milestone. If a
-subagent stalls or misses its window, wire what landed and say plainly what is
-still placeholder — never present a placeholder HUD as the finished look.
+The field failure: the entire art lane was handed to a single background agent
+that then stalled overnight, so every preview the user played showed bare CSS
+bars and the sprites they were promised only landed hours later, unseen. If art
+runs in a subagent it is a BOUNDED task you wait on, then wire and verify in
+THIS session — not an overnight handoff. While commissioned art is pending the
+HUD is unverified: do not call it done or push it as a finished milestone. If a
+subagent stalls or misses its window, wire what landed and say plainly which
+widgets are still waiting on their sprites — never present unfinished art as
+the finished look.
 
 ## Cost & latency honesty
 
-A full HUD is **~9 image generations** (mockup + deconstruct + clean + a few
-sprite re-rolls — the mockup doubles as the game concept, so there is no
-separate concept spend), a couple of minutes each at high quality — budget an
-hour end to end, not five minutes. That fits comfortably inside the image rate
-limit; local `genex ui` steps are free and instant. Two rules keep the clock
-honest: the sprite pipeline runs WHILE you build (kick Stage 1 first, code
-against CSS placeholders, swap sprites in as stages land), and the chain
-never parks behind the keep/change answer — Stage 2, the menu still, and the
-logotype enqueue the moment the mockup lands (the order-of-work rule above);
-a later "change" loops the concept at image prices.
+A full sprite HUD is **~9 image generations** (mockup + deconstruct + clean +
+a few sprite re-rolls), a couple of minutes each at high quality — budget an
+hour end to end, not five minutes. A single element is a fraction of that:
+one generation plus free local steps. That fits comfortably inside the image
+rate limit; local `genex ui` steps are free and instant. One rule keeps the
+clock honest: when the lane runs, it runs WHILE you build — enqueue with
+`--no-wait`, code the layout against plain CSS bars, swap sprites in as
+stages land, and never sit in a foreground wait.
 
 ## Publish checklist
 
@@ -658,8 +657,8 @@ a later "change" loops the concept at image prices.
 - `npx genex image` — `--size <WxH>` exact pixels (multiples of 16, each side
   ≤ 3840, aspect at most 3:1); `--quality <low|medium|high>` (high for the
   mockup/sheet, medium for single sprites); `--candidates <2|3|4>` several
-  variants in ONE call (only when the player asks for variants — the
-  doctrine is ONE concept); `--edit <url|file>` image-to-image edit of an
+  variants in ONE call (only when the player asks for variants — one mockup
+  is the default); `--edit <url|file>` image-to-image edit of an
   R2 URL or a local image file (≤4 MB, inlined); `--clean <url>`
   background removal only; `--remove-bg` chains removal after a
   generation/edit; `--bg-mode <sprite|glyph|sheet>` picks the removal model

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

@@ -1,10 +1,11 @@
-# Stage 1 prompt template — the game concept: full-HUD mockup
+# Stage 1 prompt template — the full-HUD mockup
 
 Fill the placeholders, then pass the whole text as the prompt to
 `npx genex image "<filled prompt>" --size 2560x1440 --quality high`.
-ONE concept image — no candidate variants unless the player asks for them.
-This image IS the game concept — the user's style checkpoint and the anchor
-for all later art — so the scene half deserves the same care as the HUD half.
+ONE mockup — no candidate variants unless the player asks for them. Every
+sprite the HUD ships is cut out of this frame, so the scene half deserves the
+same care as the HUD half: a HUD read against a flat grey plate looks nothing
+like the same HUD read against the game.
 
 Placeholders:
 
@@ -12,10 +13,10 @@ Placeholders:
   register ("a dark gothic action RPG", "a sun-bleached rally racing game",
   "a hand-painted storybook platformer").
 - `[GAME_SCENE]` — what's behind the HUD, written RICH and from the game
-  plan (this is the concept's scene — a thin phrase wastes the checkpoint):
-  the setting, the moment, what the player is doing right now (the verb),
-  what threatens them, what they're chasing, and the lighting. Only the
-  scene may show 3D depth — never the HUD. Examples:
+  plan (a thin phrase wastes the frame): the setting, the moment, what the
+  player is doing right now (the verb), what threatens them, what they're
+  chasing, and the lighting. Only the scene may show 3D depth — never the
+  HUD. Examples:
   - "a rain-slick neon alley mid-chase, the player character vaulting a
     barrier toward a glowing extraction gate, two drones closing in from
     behind, magenta signage cutting through blue dusk"
@@ -97,6 +98,6 @@ beside the channel, or on the frame's end caps. If the mockup comes back
 with a mid-channel label, keep it only if you'll wire that meter as
 segmented (`segments` in the masks JSON) — otherwise regenerate.
 
-The mockup is the **game concept AND the layout reference**: save its URL,
-compare the finished HUD against it, and sample runtime text colors from it
-with `npx genex ui text-color`.
+The mockup is the **style and layout reference** for everything cut out of
+it: save its URL, compare the finished HUD against it, and sample runtime
+text colors from it with `npx genex ui text-color`.

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

@@ -1,6 +1,6 @@
 ---
 name: genex-ai-menu
-description: Generate a cinematic game menu — one looping atmospheric video background plus animated DOM buttons — with `npx genex image` + `npx genex video --frame`. Use for the main menu of every game (the default tier per `genex-threejs-game-ui`'s plan gate, enqueued there with `--no-wait`; declining it needs a stated reason) and for title, victory/defeat, lobby, and credits screens that should feel like the game's opening shot; plain CSS panels are only for utilitarian overlays like pause and settings.
+description: Generate a cinematic game menu — one looping atmospheric video background plus animated DOM buttons — with `npx genex image` + `npx genex video --frame`. Reach for it when a menu wants generated art or motion: title, victory/defeat, lobby, and credits screens that should feel like the game's opening shot. Plain CSS panels stay right for restrained registers and for utilitarian overlays like pause and settings.
 ---
 
 # Genex AI · Menu
@@ -12,24 +12,28 @@ real game events.
 
 ## When to use this vs. a plain CSS menu
 
-- **Use this skill** for the main menu of every game — it should feel like the
-  game's opening shot: a title screen with weather and light, a defeat screen
-  over smoldering ruins, a lobby with the arena breathing in the background.
-  Enqueue it at `$genex-threejs-game-ui`'s plan gate with `--no-wait`.
-- **Use plain CSS** (`$genex-threejs-game-ui` alone) for utilitarian screens —
-  a quick pause overlay or a settings list. A dark translucent panel is often
-  more readable there. (The loader is NOT utilitarian: it keeps its branded
-  key-art background per the game-ui spec — "plain CSS" never means a bare
-  loading bar.) You can also get the best of both: reuse this skill's menu
-  video under a darker overlay for pause/victory variants (see Tips).
+- **Use this skill** when the menu should feel like the game's opening shot —
+  a title screen with weather and light, a defeat screen over smoldering
+  ruins, a lobby with the arena breathing in the background — or when the
+  player asks for an animated title screen. Enqueue the pieces with
+  `--no-wait` and keep building.
+- **Use plain CSS** (`$genex-threejs-game-ui` alone) when the game's register
+  is restrained, and for utilitarian screens — a quick pause overlay or a
+  settings list, where a dark translucent panel is usually more readable. A
+  title screen composed in type and light is a finished menu. (The loader is
+  never a bare bar either: it shows something of the game rather than a black
+  screen — see the game-ui loader spec.) You can also get the best of both:
+  reuse this skill's menu video under a darker overlay for pause/victory
+  variants (see Tips).
 
 ## Style brief first
 
-Use the game's ONE shared style brief from `$genex-threejs-game-ui`'s "Plan the
-UI first" gate (materials, 4–5 named hues, font pair, mood) — the menu, HUD,
-and loader all consume the same brief; don't write a second one here. The
-style is THIS game's: don't default to any stock register the examples below
-might suggest. Two hard rules for the frame prompt:
+Use the game's ONE shared style brief from `$genex-threejs-game-ui`
+(materials, 4–5 named hues, font pair, mood) — the menu, HUD, and loader all
+consume the same brief; don't write a second one here. The brief is words,
+and words are what the still is prompted from. The style is THIS game's:
+don't default to any stock register the examples below might suggest. Two
+hard rules for the frame prompt:
 
 - **Full-bleed cinematic 16:9.** The frame is a filmic establishing shot,
   edge to edge. End the prompt with: `Edge-to-edge cinematic composition.
@@ -39,19 +43,19 @@ might suggest. Two hard rules for the frame prompt:
   draws UI into the frame, the prompt was wrong — rewrite and regenerate.
 
 This dedicated UI-free **menu still is the ONLY valid `--frame` input** for
-the menu video. The game concept is the HUD mockup now (`$genex-ai-hud`
-Stage 1) — it has a HUD baked into it, so feeding it to `genex video
---frame` ships a menu with a HUD floating in the backdrop: an instant
-defect, not a shortcut. Anchor the still to the mockup with
-`--edit <mockup-url>` so menu and world share one palette and light — then
-animate the STILL.
-
-## Choose the composition — one archetype per game, justified
-
-The single most common menu failure is every game shipping the same
-left-rail layout regardless of genre. Before writing menu markup, pick ONE
-archetype and justify it from the style brief in the UI plan message
-(`$genex-threejs-game-ui`'s gate) — **defaulting to left-rail without a
+the menu video. Any image with interface in it — a HUD sheet, a gameplay
+screenshot — ships a menu with widgets floating in the backdrop: an instant
+defect, not a shortcut. When an image the menu genuinely should match already
+exists (reference art the player supplied, key art the game already ships),
+`--edit <url>` anchors the still to it so the two share one palette and
+light; otherwise prompt the still straight from the brief. Then animate the
+STILL.
+
+## Choose the composition — one archetype per game, chosen on purpose
+
+The single most common menu failure is shipping the same left-rail layout
+regardless of genre. Before writing menu markup, pick ONE archetype and have
+a reason for it out of the style brief — **defaulting to left-rail without a
 reason is the failure mode this section exists to kill:**
 
 - **Left rail** — title upper-left or top, buttons stacked left of center
@@ -77,11 +81,11 @@ reason is the failure mode this section exists to kill:**
   stack at all. Fits: art games, ambient toys. Delta: 2–3 small text links
   bottom-left, heavy letter-spacing, nothing over the subject.
 
-**Second choice — button treatment,** stated in the same line: bare text
+**Second choice — button treatment,** decided with it: bare text
 (cinematic, the example below) / CSS plate (styled FROM the brief —
 gradients, borders, chamfers per the game-ui corner rules; default-gray
-plates are a defect) / sprite chrome (from the HUD sheet or a dedicated
-generation — Tier 2b, when the brief is ornate) / real glass
+plates are a defect) / sprite chrome (from a HUD sheet or a dedicated
+generation, when the brief is ornate) / real glass
 (`npx genex image "<frosted panel>" --glass` — menus love frosted panels,
 and the solved RGBA carries TRUE translucency over the moving backdrop;
 `$genex-ai-image` documents the lane). The per-genre lean lives
@@ -115,10 +119,10 @@ references/style-capsules.md) — a lean, not a rule.
 
 ```bash
 # 1. The frame — a still of the scene the loop returns to (this example is a
-# painterly meadow; YOUR prompt comes from YOUR game's style brief). Anchor
-# the still to the concept mockup with --edit <mockup-url> so menu and world
-# share one palette and light (the still stays UI-free; the mockup itself is
-# NEVER the video frame — it has a HUD in it):
+# painterly meadow; YOUR prompt comes from YOUR game's style brief, in words).
+# If the menu should match an image that already exists, add --edit <url> so
+# the two share one palette and light. The still stays UI-free — an image
+# with interface in it is never the video frame:
 npx genex image "windswept alpine meadow at golden hour, wildflowers leaning in the gusts, painterly light, cinematic wide shot. Edge-to-edge cinematic composition. Full-bleed 16:9 frame. No UI elements, no text, no buttons in the frame." --aspect 16:9 --quality high
 # -> https://assets.genex.technology/generations/<id>/image-main
 
@@ -132,7 +136,7 @@ npx genex wait <gen-id>
 # -> https://assets.genex.technology/generations/<gen-id>/video-mp4
 ```
 
-## Seamless in the DOM — the loop crossfade (mandatory wiring)
+## Seamless in the DOM — the loop crossfade (how every menu video is wired)
 
 Never wire the clip as a bare `<video loop>` — the residual seam shows every
 cycle. Two stacked `<video>` elements with the same src crossfade at the
@@ -179,34 +183,29 @@ wired it is the menu's capture in the milestone smoke pass: one full loop
 cycle watched AS RENDERED. A metadata probe (ffprobe) can't see a seam, a
 panel covering the video, or a video that never plays — only watching can.
 
-**Work async — the menu must never block the game.** The still is
-`--edit`-anchored to the concept mockup, so it's style-dependent: enqueue it
-`--no-wait` **the moment the concept mockup LANDS** — it rides the same
-immediate chain as the HUD Stage-2 sheet and the logotype; the user's
-keep/change answer never gates it (a later "change" just re-edits it against
-the new frame, image-priced). **Only the VIDEO — the expensive item — waits,
-and its trigger is an event, never a clock: fire it at the FIRST of (a) the
-user's yes to the concept, (b) the next `genex preview` push after the still
-has landed (a shipped milestone with the user silent = the pick stands), or
-(c) style art being the only work left. Never fire it while a user objection
-is open** ("change the colors" blocks it until the loop resolves). Ship the
-CSS menu (buttons + title over the frame IMAGE as a static backdrop) and
-swap the `<video>` in when `genex wait` prints the URL. The frame image doubles as the
+**Work async — the menu must never block the game.** The still is prompted
+from the brief, so it can go out the moment you know the look: enqueue it
+`--no-wait` and keep building. **The video is the slow, expensive item** —
+generate it once you've decided the menu wants motion, or the player asks for
+it, and never while a style objection is open ("change the colors" waits
+until the look settles, or you pay for the loop twice). Ship the CSS menu
+(buttons + title over the frame IMAGE as a static backdrop) and swap the
+`<video>` in when `genex wait` prints the URL. The frame image doubles as the
 **loading screen background** — it exists minutes before the video does (see
 `$genex-threejs-game-ui`'s loader spec). Both assets live in Genex storage
 (R2) — permanent, public, CORS-open; you load them straight from the printed
 URLs, nothing is downloaded or committed.
 
 **When the generated art lands, the upgrade is a RE-COMPOSITION — not a
-backdrop swap.** DELETE the placeholder panel/card the moment the still or
-video goes in: the still was generated with negative space precisely so the
-buttons and logo sit DIRECTLY on the key art. A placeholder card left
-floating over the finished video is the single most common bad menu — a
-near-opaque panel (plus its darkening layers) hides the art you just paid
-for, and the menu reads as the plain CSS draft it started as. Allowed over
-the art: a thin, low-opacity scrim strictly behind the button rail for
-legibility, and at most ONE subtle full-screen grade layer. NEVER a
-card/panel covering the art.
+backdrop swap.** DELETE the panel/card that carried the buttons while the art
+rendered, the moment the still or video goes in: the still was generated with
+negative space precisely so the buttons and logo sit DIRECTLY on the key art.
+A card left floating over the finished video is the single most common bad
+menu — a near-opaque panel (plus its darkening layers) hides the art you just
+paid for, and the menu reads as if it never landed. Allowed over the art: a
+thin, low-opacity scrim strictly behind the button rail for legibility, and
+at most ONE subtle full-screen grade layer. NEVER a card/panel covering the
+art.
 
 **Two failed video attempts = ship the still. Hard stop.** Video is the one
 generation that fails server-side with real frequency (render timeouts), and
@@ -364,13 +363,13 @@ One display font + one body font per menu. Give text its own contrast against
 the moving video — layered text-shadows or a subtle dark plate (avoid heavy
 text strokes — they read as a browser game, not a title screen).
 
-**Title treatment — the generated logotype is the DEFAULT, not an upsell.**
-Every game with a menu gets a generated wordmark (Tier 2; skipping it needs
-a one-line stated reason in the UI plan message — "the brief is minimal
-fullbleed and a set wordmark would fight the vista" is a reason; silence is
-not):
+**Title treatment — a drawn wordmark, or type set well.** Generate the
+logotype when the menu wants drawn lettering: an ornate, crafted, or comic
+register, a name that IS the game's identity, a player who asks for one. When
+the brief is restrained — minimal fullbleed, a vista a set wordmark would
+fight — the title in the display font is a finished title, not a stand-in:
 
-- **Logotype (default yes):**
+- **Logotype:**
   `npx genex image "the word 'EMBERFALL' as an ornate engraved game logo, <style brief>" --transparent`
   — the wordmark alone on a transparent background, in the brief's display
   register, no extra text or scenery. Then trim with `npx genex ui trim`.
@@ -390,9 +389,9 @@ not):
   words) come out best. Wire it as the menu title AND the loader mark; the
   DOM keeps an accessible text fallback (`aria-label` or visually-hidden
   text).
-- **Layered CSS (the fallback while it renders, or the stated-reason
-  skip):** gradient ink via `background-clip: text` + stacked shadows (a
-  tight dark one for contrast, a wide soft one for glow).
+- **Layered CSS (a finished title on its own, and the stand-in while a
+  wordmark renders):** gradient ink via `background-clip: text` + stacked
+  shadows (a tight dark one for contrast, a wide soft one for glow).
 
 ## Tips
 
@@ -402,10 +401,10 @@ not):
 - **One menu = ONE video, generated one-off — not iteratively.** Video
   generation is strictly rate-limited and takes minutes per attempt. Get the
   still frame right first (images are cheap to redo), then animate it once.
-  The one exception: a user-driven style change (the game-ui concept loop
-  re-anchored the look) re-opens this rule once — re-edit the still
-  (`--edit` against the new concept mockup) and re-run the video from the
-  new still. Agent-initiated polish never does.
+  The one exception: a user-driven style change re-opens this rule once —
+  re-prompt the still against the new direction (or `--edit` it against the
+  new reference) and re-run the video from the new still. Agent-initiated
+  polish never does.
 - **The menu video renders 1080p by default — leave it alone.** Every video
   path, the frame-conditioned (`--frame`) menu route included, defaults to
   1080p: the menu clip is full-screen key art, and 720p stretched across a
@@ -448,7 +447,7 @@ not):
 - `--aspect 16:9 --quality high` (image) — the right settings for a menu frame.
 - `--no-wait` — enqueue and return immediately with the generation id; pick
   the result up later with `npx genex wait <id>` (safe to re-run — it attaches
-  to the SAME generation). The default for menu videos: build while it
+  to the SAME generation). It is how a menu video is run — build while it
   renders. Re-running the GENERATE command, by contrast, creates (and bills)
   a new one.
 

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

@@ -111,7 +111,7 @@ model.traverse((o) => {
   m.envMapIntensity = Math.min(m.envMapIntensity, 0.8);
 });
 // If a model that SHOULD read metallic still looks dull, this clamp is not the
-// cause — check the model against the concept and lift per-material as needed.
+// cause — check the model against the brief and lift per-material as needed.
 model.scale.setScalar(1); // tune to taste
 model.position.set(0, 0, 0);
 scene.add(model);