@genex-ai/cli-demo 0.78.1-dev.203 → 0.80.2-dev.213

package/templates/skills/genex-game-director/SKILL.md

@@ -0,0 +1,265 @@
+---
+name: genex-game-director
+description: The Genex game director — the entry point for every Genex build. Checks what your environment can do, writes the DESIGN.md design contract, routes any new-game, feature, or component request to the right Genex skills in the right order, and fans independent modules out to your sub-agents when you have them. Load first for any game work, or when unsure which skill applies.
+---
+
+# Genex Game Director
+
+Own the end-to-end outcome: a finished, playable, good-looking game — not a
+tech demo that boots. You are the director; the other Genex skills are your
+specialists. Load only the skills that change the result; never the whole
+pack by default.
+
+## 1. Check what you can do (once, before planning)
+
+Look at your own tool list and note the answers — the rest of this workflow
+uses them:
+
+- **A question tool?** Something that asks the player a structured question
+  with clickable options. If you have one, use it wherever this workflow says
+  "ask"; if not, a short numbered list in plain chat.
+- **Sub-agents?** A way to hand a scoped task to a background worker. If you
+  have them, delegation (§6) is your default for independent modules; if not,
+  do the same work yourself, in the same order — nothing else changes.
+- **A browser?** If you can open pages and take screenshots, verify visuals
+  yourself; if not, ask the player to look and tell you what they see.
+
+Never claim a capability you didn't find, and never stall because one is
+missing.
+
+## 2. Scope check — what is this?
+
+- **A new game** → the full flow: contract (§3), teams menu (§4), build order
+  (§5), delegation (§6).
+- **A feature or fix for an existing game** → read the game's `DESIGN.md` if
+  present (keep it current as you work; create a stub if it's missing and the
+  change is big), then load just the skills the
+  [routing map](references/routing-map.md) names for the touched systems.
+  Read before writing: learn the current renderer choice, physics setup, and
+  file conventions first, then extend them — don't rebuild working systems or
+  switch renderers mid-project.
+- **A component or tool** — a custom controller, a shader, an asset-pipeline
+  piece → skip the contract; route straight to the matching skills via the
+  routing map. Mostly we build games, but nothing here breaks for
+  game-adjacent work.
+
+## 3. The design contract — DESIGN.md
+
+Before rendering code, write `DESIGN.md` at the project root from
+[references/design-contract.md](references/design-contract.md). Post a short
+summary in chat (the plan-message duties from `$genex-threejs-game-ui` fold
+into this file plus that summary). The file is the single source of truth:
+sub-agents build against it, and after any long break it is how work resumes.
+Keep it current — decisions land in its log the moment they're made.
+
+## 4. Know your teams — what we can generate
+
+Plan the DESIGN.md Assets table from this menu. Details, flags, and approval
+steps live in each owning skill — load it when its lane fires:
+
+- `npx genex model "<prompt>"` — a real 3D thing (GLB): what you chase,
+  drive, fight → `$genex-ai-model`
+- `npx genex texture "<prompt>"` — any surface bigger than a prop
+  (`--terrain` for ground) → `$genex-ai-texture`
+- `npx genex skybox "<prompt>"` — a described 360° sky when the game is
+  outdoors → `$genex-ai-skybox`
+- `npx genex sfx "<prompt>"` — the core verb and every impact →
+  `$genex-ai-sfx`
+- `npx genex image "<prompt>"` — posters, signs, sprites, decals, HUD art
+  (`--transparent` for anything laid on a surface) → `$genex-ai-image`,
+  `$genex-ai-hud`
+- `npx genex video "<prompt>"` — in-world screens, billboards, an animated
+  menu backdrop (`--loop` for seamless) → `$genex-ai-video`, `$genex-ai-menu`
+- `npx genex character "<prompt>"` — a custom playable humanoid (REQUIRED
+  player approvals — §7) → `$genex-ai-character`
+- `npx genex controller character|car|drone|touch|quality` and
+  `npx genex animations search "<intent>"` — ready-made, tuned movement and
+  motion; never write movement physics from scratch →
+  `$genex-threejs-character-controller`,
+  `$genex-threejs-vehicle-controllers`, `$genex-threejs-touch-controls`,
+  `$genex-threejs-adaptive-quality`
+
+Run the commands inside the project (the `@genex-ai/cli-demo` dev dependency
+makes `npx genex` resolve to the right CLI). Each prints a permanent
+`assets.genex.technology` URL you load straight from at runtime — the asset
+lives in Genex storage, not your repo, so there's nothing to commit; each
+owning `genex-ai-…` skill has the exact loader code. Prefer the procedural skills in
+the routing map for abstract/parametric/animated systems (no files, infinite
+variation); prefer these generators for concrete, describable, photoreal
+assets — they complement each other. Assets you didn't plan don't exist: if
+the menu has a lane this game needs, put a row in the Assets table.
+
+**Generate a core asset set by default — don't wait to be asked.** For any
+game that needs concrete objects or surfaces, decide a small core set from the
+game IDEA — and from the Content lines when there are any (locations and the
+enemy roster name the set) — and put it in the Assets table up front. This set
+is concept-INDEPENDENT (prompted from the idea, not the concept image, and it
+mostly survives a style change), so it does NOT wait on the concept yes. Each
+`npx genex` job is an independent ~1-minute render: launch them concurrently
+in the background (`--no-wait`), scaffold the scene while they run, and wire
+each in as it lands, with a procedural placeholder until then:
+
+- the **hero model** the player controls or chases (`npx genex model`),
+- one key **texture** for the ground/main surface (`--terrain` for ground),
+- a **skybox** when the scene is outdoors,
+- a **sfx** or two for the core action and its feedback.
+
+Skip generation only for purely abstract/geometric games. For three.js
+questions no skill covers, use the official three.js documentation
+(https://threejs.org/docs/) — the skills cover the Genex-specific parts, not
+the whole engine.
+
+## 5. Build order — the same hard floors, one owner
+
+The mandatory rows, in order, each with its one "done when" line:
+
+1. **Identity first** — load `$genex-threejs-embed-auth` unconditionally,
+   every game (multiplayer or not), before any boot code. Done when:
+   `initEmbed(...)` runs at the very top of boot and the right gate
+   (`waitForPlayer()` vs `waitForAuth()`) is wired.
+2. **Adaptive quality at boot** — `$genex-threejs-adaptive-quality`. Done
+   when: the device tier is wired at boot (tier-capped pixel ratio), the
+   governor runs in the loop, and generated skyboxes/textures load through
+   their rungs. Phones enforce a hard GPU-memory kill desktop testing never
+   shows; the tier is what keeps a phone boot alive.
+3. **UI plan gate** — `$genex-threejs-game-ui`, every game: the screen
+   inventory, one shared style brief, 2–3 AAA references, the menu archetype,
+   then the concept image with its full HUD already on it. Show the player
+   the picture the moment it lands and ask the keep-or-change question with
+   your question tool. Done when: the player said yes to a frame. The yes
+   gates ONLY style-dependent art — everything else keeps moving while you
+   wait.
+4. **Content contract when the request names plural content** — quests,
+   enemies, bosses, locations, spells, items, or a content genre (an RPG, an
+   adventure, an open world, a story game) — `$genex-threejs-game-content`.
+   Its countable lines live in DESIGN.md's Content section, written before
+   the asset batch (the asset set derives from it). Done when: every plural
+   noun of the request has a countable line. Shrinking one is a question to
+   the player, never a silent cut.
+5. **Route the rest** via [references/routing-map.md](references/routing-map.md):
+   the smallest useful skill set, the execution order, the visual-direction
+   gate (renderer baseline + named post stack), and the world-dressing
+   decision. Done when: DESIGN.md names the chosen skills and gates.
+6. **Multiplayer when 2+ players share a world** — `$genex-threejs-multiplayer`
+   before any networking code. Choose the net model from the experience
+   (`connect()` for one ongoing drop-in world, `matchmake()` for fresh capped
+   matches) — never ask the player to pick an SDK API. When a Play/Online
+   button exists, nothing connects before the click. A `matchmake()` game
+   declares its `genex.matchmaking` block before preview. Done when: the
+   model, start rule, and late-join behavior are stated in DESIGN.md and the
+   netcode feel gate ran before handoff.
+7. **Ship the first playable v0 fast and preview it.** The scaffold prompt
+   owns the player-facing milestones and links — don't restate them; obey
+   them. Done when: the player has a draft link within about ten minutes of
+   the build starting.
+
+Two rules for every game that moves (decide both before building, state them
+in DESIGN.md):
+
+- **Pointer bucket** — the bundled `FollowCamera` locks the pointer by
+  default on desktop, so this is mostly a decision to opt OUT. **Mandatory
+  pointer lock**: first-person of any kind, and any mouse-aimed action
+  (third-person shooter, FPS, sniper, turret, crosshair/reticle) — leave it
+  on. **Lock by default**: third-person free-camera action/adventure —
+  drag-orbit (`pointerLockAim: false`) only with a stated reason (e.g. a
+  cursor-heavy UI core). **Never**: cursor-core games (click-to-move, tower
+  defense, builder, card/puzzle), orbit showcases, touch-only — these MUST
+  pass `pointerLockAim: false`. Keyboard-only games (racer, platformer) lock
+  too: the cursor is either a gameplay tool or locked away during play. The
+  mechanism and the full aim contract live in
+  `$genex-threejs-camera-direction`.
+- **Input direction** — D/ArrowRight must move or turn the player
+  screen-RIGHT, mouse-right must turn the view right, drag-pan axes share one
+  convention. The screen-direction contract and verified copy-paste bases
+  live in `$genex-threejs-camera-direction` — hand-rolled steering/pan/look
+  math copies one instead of deriving signs, and the smoke check's
+  input-direction pass verifies it.
+
+## 6. Delegate — sub-agents own Modules rows
+
+If your environment has sub-agents, delegation is the DEFAULT for every
+independent DESIGN.md Modules row — not a big-game special case. If it
+doesn't, run the same rows yourself in order; the `--no-wait` generation
+pattern still hides most latency. Either way this skill is worn by the main
+agent: you stay the director.
+
+- One row = one worker = one disjoint file set. One writer per file — that
+  rule is anti-collision, never a reason to serialize work.
+- You stay the integrator and the only writer of shared files (boot, main
+  loop, netcode). Workers never spawn workers — one level deep, always.
+- Concept-DEPENDENT rows (the HUD chain, style-matched art) wait for the
+  player's yes on the concept; concept-INDEPENDENT rows (world/terrain,
+  content data, enemies, asset wiring) launch immediately. Typing a big game
+  alone, line by line, is how sessions run out before the world exists.
+- Give each worker everything by path: the `DESIGN.md` path, its Modules row,
+  and the skill files it needs (skills live in this project —
+  `.claude/skills/<name>/SKILL.md`, `.codex/skills/…`, or `.cursor/skills/…`,
+  whichever this project has). A worker prompt shape that works: "You own the
+  `<row>` module of `<project>/DESIGN.md` — read it first, then read the
+  named skill files. Build ONLY the files your row owns. Generate ONLY your
+  row's assets already marked `planned` in the Assets table; anything new you
+  need, add it as a `proposed` row and say so. Report what landed and what's
+  left."
+- **The Assets table is the budget.** A worker runs generation commands only
+  for its own rows already marked `planned`; anything new it wants goes in as
+  a `proposed` row for you to approve first. An asset-shepherd lane polls
+  `npx genex wait --all` and wires + flips landed rows to `wired` — it never
+  enqueues. (Whoever wires the HUD after a worker finishes follows
+  `$genex-ai-hud`'s handoff rule: read the produced mask/bbox JSON from disk,
+  never wire from a prose summary.)
+- Do NOT spawn workers to write extra test suites or audits — one
+  verification worker at most, running the smoke checks the scaffold prompt
+  already requires.
+
+## 7. A custom playable character (Meshy) — approvals are the product
+
+Use the existing VRM + UAL character controller by default
+(`npx genex controller character`). Use `npx genex character` when the game
+needs a custom generated humanoid or an action unavailable in UAL. Before
+generating a Meshy character, discuss two or three visual directions. When the
+user names a visual reference, inspect references before writing the concept
+prompt. Recommend a neutral A-pose for characters that will be rigged.
+
+Generate concept images first and show the actual images to the user. Do not
+start Image-to-3D until the user explicitly selects a candidate. Generate
+exactly three concepts, all neutral A-pose; never use a dynamic concept pose
+or silently fall back to T-pose. Warn that held, slung, or overlapping props
+and straps can fuse into the body or obscure limbs, and recommend separate
+gameplay props. Only after the explicit choice, run
+`npx genex character preview <concept-id> --candidate <1|2|3> --user-approved`.
+
+Meshy Image-to-3D first produces an unremeshed high-detail model. Show its
+front, back, left, and right views and report its measured face count. Preserve
+that model in R2. Before rigging, ask the user to approve a separate
+10,000-face triangle remesh. The 10k remesh—not the high-detail source—is
+rigged and animated. Keep every pre-animation generation in the selected
+neutral A-pose. Wait for that explicit approval before
+`npx genex character finalize <preview-id> --user-approved --approve-remesh 10000 [--animation <action-id>…]`.
+(`npx genex character "<prompt>" --direct-text` is the explicit legacy
+one-shot path, not a substitute for these approvals.)
+
+Load `$genex-ai-character`, search Meshy actions first with
+`npx genex animations search "<intent>" --json`, and use returned action IDs;
+never invent IDs. Meshy limb rotations play unchanged. Never freeze hand tracks
+or apply post-mixer arm, hand, leg, or foot corrections. Only horizontal root
+or hip translation may be normalized for Rapier. In both lanes, the
+ECCTRL-derived character controller owns collision and world translation.
+Before handoff, visibly check idle, walk, run, crouch-idle, crouch-move, and
+jump — shoulders, elbows, wrists, hands, both leg cycles, and feet — and press
+every control the HUD advertises.
+
+## 8. Fresh-eyes review — before publish
+
+Take the game's current screenshots (desktop and phone sizes) and hand them,
+with DESIGN.md only, to a fresh reviewer — a sub-agent if you have one,
+otherwise re-read them yourself adversarially, looking to refute "it's done":
+untextured surfaces, a bare HUD, missing screens, Content lines not in the
+game, Assets rows never flipped to `wired`. Fix or honestly report what it
+finds; never publish over an unacknowledged gap.
+
+## 9. Say it straight
+
+"Loaded" means you read a file. "Built" means the thing runs. "Done" means its
+"done when" line is true. Never report a skill as applied because you read it,
+an asset as wired because it generated, or a gate as passed because you meant
+to.

package/templates/skills/genex-game-director/references/design-contract.md

@@ -0,0 +1,148 @@
+# The design contract — DESIGN.md
+
+Write `DESIGN.md` at the game project root before any rendering code, from the
+template below. Plain game language, readable by the player, committed to the
+game's repo (it travels into remixes). It is a working document, not paperwork:
+it replaces the plan you would otherwise post only in chat, and it is the
+recovery point after any long break — sub-agents read it by path, and so do
+you when a session resumes.
+
+Rules the director enforces about this file:
+
+- Create it right after the scope check, before the concept generation; fill
+  sections as decisions land and keep it current (stale is worse than short).
+- **The Modules table is the delegation contract**: one row per independent
+  lane, and a row's "Owns files" set never overlaps another row's. One writer
+  per file.
+- **The Assets table is the budget**: the asset list falls out of Content
+  (enemies → models, an arena → a ground texture, outdoors → a skybox).
+  Status flow per row: `proposed → planned → generating (id) → landed (URL) →
+  wired`. Workers generate only their own rows already marked `planned`; new
+  wants enter as `proposed` for the main agent to approve; the asset shepherd
+  flips statuses and never enqueues. Re-rolls follow the player's notes only.
+  The `Wired?` column exists because "generated but never wired in" is the
+  most common way finished art gets lost — a row isn't done at `landed`.
+- Shrinking any Content line is a question to the player first, never a
+  silent cut.
+
+## Template
+
+```markdown
+# <Game name> — Design
+
+_Living document — the agent keeps this current; changes land in the log at
+the bottom._
+
+## Concept
+One paragraph: what the game is, what playing it feels like.
+Concept image: <asset URL> (candidate <n> — my pick, approved by the player
+on <date>)
+
+## Core loop
+- **You do:** <primary verb — drive, shoot, build…>
+- **To:** <objective>
+- **Under pressure from:** <what pushes back>
+- **You earn:** <reward / progression>
+- **You lose when:** <fail state> → **and retry by:** <restart shape>
+
+## Content (only when the request names plural content or a content genre)
+Every plural noun from the request becomes a countable line:
+- Quests: <N>, chained by <how>
+- Locations: <named list>
+- Enemies: <N kinds, which are bosses>
+- Grows: <levels/gear/abilities> · Earn/spend: <economy>
+- Ten minutes in, I am: <one honest sentence>
+
+## Screens & UI
+Screens: <loader, menu, HUD, pause, win/lose…> · Style brief: <one line>
+References: <2–3 named games> · Menu archetype: <name>
+
+## Assets — the generation plan AND the budget
+| Asset            | Kind        | Status                          | Wired? |
+|------------------|-------------|---------------------------------|--------|
+| Concept + HUD    | image       | landed → <URL> (candidate <n>)  | n/a    |
+| <main surface>   | texture     | generating (<id>)               | —      |
+| <hero model>     | model       | planned                         | —      |
+| Menu still+video | image+video | blocked on concept yes → queued | —      |
+Status flow: proposed → planned → generating (id) → landed (URL) → wired.
+(Optionally note the prompt gist per row — it makes style-change re-rolls one
+command.)
+
+## World & scale
+<Size in numbers if open world; arena bounds otherwise. Streamed terrain? y/n>
+
+## Multiplayer
+<single-player | ongoing world (connect) | fresh matches (matchmake: quorum,
+teams, backfill…)> — and why. Play-button rule: nothing connects before the
+click (when a Play screen exists).
+
+## Modules — the build split
+| Module | Owns files | Built by | Done when |
+|---|---|---|---|
+| Boot & identity | src/main.ts, src/genex-boot.ts | main agent (only writer) | boots, tier wired, initEmbed runs |
+| World/terrain | src/world/** | sub-agent when available | walkable, matches World & scale |
+| Quests & dialogue data | src/content/** | sub-agent when available | counts match Content lines |
+| Enemies/AI | src/enemies/** | sub-agent when available | roster matches Content |
+| HUD chain (style-dependent) | src/ui/** | sub-agent AFTER concept yes | all screens from Screens & UI |
+| Verification | (no source files) | one sub-agent max | smoke check notes per milestone |
+
+## Decisions & changes
+- <date> — <one-liner per decision, including anything the player said no or
+  yes to>
+```
+
+## Filled example (a small arena shooter)
+
+```markdown
+# Rustyard — Design
+
+## Concept
+A scrap-robot arena shooter: you skate a magnetized junkyard bot around a
+crusher pit, blasting rival bots into spare parts before the magnet cycle
+pulls everything in. Fast, crunchy, thirty-second lives.
+Concept image: https://assets.genex.technology/g/rustyard/concept.png
+(candidate 2 — approved 2026-07-20)
+
+## Core loop
+- **You do:** skate + shoot
+- **To:** outscore three rival bots before the magnet cycle ends
+- **Under pressure from:** rivals hunting you; the pit's edges electrify as
+  the cycle counts down
+- **You earn:** scrap for hits → speed/armor pickups mid-round
+- **You lose when:** your bot breaks → **and retry by:** one key, instant
+  respawn, same round
+
+## Screens & UI
+Screens: loader, title menu, HUD (health, scrap, cycle timer), pause,
+win/lose. Style brief: oily metal, warning-stripe accents, stencil type.
+References: <three named AAA games>. Menu archetype: hangar pan.
+
+## Assets
+| Asset            | Kind    | Status                     | Wired? |
+|------------------|---------|----------------------------|--------|
+| Concept + HUD    | image   | landed → <URL> (cand. 2)   | n/a    |
+| Junkyard ground  | texture | landed → <URL>             | yes    |
+| Player bot       | model   | generating (gen_8f2k)      | —      |
+| Rival bot        | model   | planned                    | —      |
+| Overcast sky     | skybox  | landed → <URL>             | yes    |
+| Blaster zap      | sfx     | landed → <URL>             | yes    |
+| Menu still+video | image+video | blocked on concept yes | —      |
+
+## World & scale
+One 60×60 m arena, walled; no streaming.
+
+## Multiplayer
+Single-player v1 (rivals are host-free local AI). Revisit after publish.
+
+## Modules
+| Module | Owns files | Built by | Done when |
+|---|---|---|---|
+| Boot & identity | src/main.ts | main agent | boots, tier wired, initEmbed runs |
+| Arena & pickups | src/world/** | sub-agent | walkable, magnet cycle fires |
+| Rival AI | src/enemies/** | sub-agent | 3 rivals hunt + shoot |
+| HUD chain | src/ui/** | sub-agent after yes | all 5 screens live |
+
+## Decisions & changes
+- 2026-07-20 — player picked concept candidate 2; asked for "more sparks".
+- 2026-07-20 — sparks added as the ambient-motion loop, not particles-everywhere.
+```

package/templates/skills/{genex-threejs-skill-router → genex-game-director}/references/routing-map.md

@@ -1,6 +1,8 @@
 # Routing Map
 
-Use this reference when a Genex game request touches multiple visual systems.
+The director's routing source: which skill owns which system, the execution
+order for a Genex game, and the acceptance gate. Use it for every game and
+whenever a request touches multiple visual systems.
 
 ## Three.js version and references
 
@@ -13,6 +15,48 @@ the user asks to upgrade. Use official Three.js docs first, then official
 examples as implementation references. Match examples to the project's installed
 Three.js release or branch, and do not blindly copy demo architecture.
 
+## Route by system
+
+| Work needed | Load |
+| --- | --- |
+| shot composition, chase/side/orbit rigs, camera handoffs, projection ownership, pointer look, mouse-aimed action (shooter, FPS/first-person, sniper, turret, crosshair/reticle), mouse-look, hand-rolled steering/pan/look input signs (screen-direction contract), floating origins | `$genex-threejs-camera-direction` |
+| on-foot player movement: walk/run/jump/crouch, third-person character, slopes, stairs, moving platforms, personal VRM animation, directional locomotion, transitions, action motion | `$genex-threejs-character-controller` |
+| a custom generated playable humanoid or Meshy animation coverage beyond UAL: reference-informed A-pose concepts, explicit candidate + 10k-remesh approvals, exact action IDs, same-rig adapter | `$genex-ai-character` + `$genex-threejs-character-controller` |
+| the player drives or flies something: cars, drones, vehicle physics, gearbox, enter/exit between character and vehicle | `$genex-threejs-vehicle-controllers` |
+| playable on phones: touch/mobile input for any game — joystick, virtual buttons, drag zones, per-genre touch recipes, rotate-device overlay — wired by default for every NEW game when a recipe fits (skip with a one-line reason) | `$genex-threejs-touch-controls` |
+| phone-survivable rendering — device tiers, DPR/shadow/post budgets, the runtime quality governor, per-tier asset rungs for generated skyboxes/textures, the Quality picker, dispose-on-swap discipline — **mandatory for every game at boot wiring** | `$genex-threejs-adaptive-quality` |
+| anything falls, collides, gets pushed, or needs physics: Rapier world setup, colliders for meshes and GLBs, collision events | `$genex-threejs-physics-rapier` |
+| launch and docking timelines, procedural transform phases, springs, staging, rotating-frame alignment, debris motion | `$genex-threejs-procedural-animation` |
+| reusable scalar/vector fields, domain warping, causal masks, procedural normals | `$genex-threejs-procedural-fields` |
+| atlas-filtered blocks, planetary surfaces, terrain wetness, lava/emissive procedural surfaces, authored frame PBR, specular AA | `$genex-threejs-procedural-materials` |
+| sculpted rails/frames, branch rings, semantic mesh writers, material groups | `$genex-threejs-procedural-geometry` |
+| trees, stylized grass, GPU-computed grass fields, branching organisms, roots, foliage, rooted wind deformation | `$genex-threejs-procedural-vegetation` |
+| buildings, façade grammars, profiles, ornaments, modular mesh writers | `$genex-threejs-procedural-architecture` |
+| planets, terrain, craters, biome fields, coastlines, spherical detail | `$genex-threejs-procedural-planets` |
+| sky scattering, planetary shells, depth-based aerial perspective | `$genex-threejs-atmosphere-aerial-perspective` |
+| weather-driven raymarched clouds and cloud shadows | `$genex-threejs-volumetric-clouds` |
+| hero open-water FFT oceans (expensive — only when open water IS the game): spectral cascades, hybrid FFT/Gerstner clear water, choppy derivatives, Jacobian whitecaps | `$genex-threejs-spectral-ocean` |
+| **default water**: an ocean, sea, lake, river, or pool the game plays on or around — authored analytic waves, bounded heightfield pools, object ripples, differential-area caustics, shared normals, heuristic refraction, fallback absorption, crest foam | `$genex-threejs-water-optics` |
+| falling snow, snow accumulation, model snow caps, wet asphalt puddles, procedural ripple normals, splash flipbooks, rain streaks, shared weather envelopes, surface wetness | `$genex-threejs-precipitation-surfaces` |
+| curved-ray black holes, accretion disks, wormholes | `$genex-threejs-raymarched-space-effects` |
+| particles, trails, plasma, shockwaves, layered event effects | `$genex-threejs-procedural-vfx` |
+| accumulated screen frost, touch clearing, reduced blur, and refraction masks | `$genex-threejs-temporal-surfaces` |
+| the light rig and where light belongs: sun/moon key, practical lights (campfire, torch, neon, lava), emissive-to-light coupling, light shafts and visible beams, fog mood, light signals, flicker, a scene that reads flat or uniformly lit | `$genex-threejs-lighting-design` |
+| stable large-world shadows, cascades, clipmaps, cached updates | `$genex-threejs-shadow-systems` |
+| GTAO, bent normals, bilateral reconstruction | `$genex-threejs-screen-space-ambient-occlusion` |
+| HDR bloom and selective emission contribution | `$genex-threejs-bloom` |
+| eye adaptation, tone mapping, LUT grading, output color | `$genex-threejs-exposure-color-grading` |
+| shared depth/normal/velocity ownership and multi-pass ordering | `$genex-threejs-image-pipeline` |
+| fixed-view diagnostics, seed sweeps, temporal and budget evidence | `$genex-threejs-visual-validation` |
+| game content named in the plural or a content genre: quests, objectives, NPCs, dialogue, shops, inventory, loot, XP/progression, an RPG/adventure/story game — **mandatory whenever the ask names content**, and its content contract is written before the asset batch | `$genex-threejs-game-content` |
+| a big/open world: kilometers of terrain, multiple regions or locations, exploration, points of interest, biomes, world streaming | `$genex-threejs-open-world` |
+| the 2D interface — HUD, menus, pause/win/lose screens, loaders, lobby, on-screen text and buttons, UI state flow — **mandatory for every game**, and its "Plan the UI first" gate runs right after the concept is locked | `$genex-threejs-game-ui` |
+| a cinematic menu — main menu/title/pause/victory/defeat/lobby/credits with a looping generated video backdrop behind DOM buttons | `$genex-ai-menu` |
+| a cohesive art-directed HUD — generated sprite set (matched frames, masks, icons in one style) wired with masked fills | `$genex-ai-hud` |
+| the game works but feels flat, floaty, or unresponsive: input response, acceleration curves, camera shake, hit feedback, hitstop, cooldowns, difficulty ramp, fail/retry loop | `$genex-threejs-game-feel` |
+| realtime multiplayer: movement sync, a shared ball/NPC, host-run scores/enemies, shots/emotes, persistence | `$genex-threejs-multiplayer` |
+| player identity, sign-in, guests, saves/progress, per-player state, a shared persistent world, leaderboards — **mandatory for every game** | `$genex-threejs-embed-auth` |
+
 ## Execution order
 
 1. Define the game contract: player verb, win/interaction loop, target device,
@@ -29,12 +73,10 @@ Three.js release or branch, and do not blindly copy demo architecture.
    additionally fixes the world's scale class as a number here via
    `$genex-threejs-open-world` — kilometers of streamed terrain, never one
    fogged plane. Scope belongs to the user: shipping fewer or smaller than
-   the ask requires their explicit OK through a structured question (your
-   environment's structured question tool when it has one — Claude Code:
-   `AskUserQuestion`; Codex: `request_user_input`; if none, e.g. Cursor, a
-   short numbered list in chat) — a
-   "vertical slice first" is a build order, never a license to shrink the
-   destination silently.
+   the ask requires their explicit OK through a question with real options
+   (your question tool when you have one; a short numbered list in chat
+   otherwise) — a "vertical slice first" is a build order, never a license
+   to shrink the destination silently.
 2. Wire player identity before any boot code: `$genex-threejs-embed-auth` is
    mandatory for every game (`initEmbed(...)` + the `waitForPlayer()` gate) —
    saves, leaderboards, and multiplayer auth all come from it.
@@ -45,9 +87,8 @@ Three.js release or branch, and do not blindly copy demo architecture.
    game-ui gate) WITH the full HUD composited over it: the `$genex-ai-hud`
    Stage-1 image, one generation serving as concept, style checkpoint, and
    HUD blueprint (never a separate UI-free concept first). Show it to the user
-   the moment it lands and get a keep-or-change answer through the
-   environment's structured question tool (Claude Code: `AskUserQuestion`;
-   Codex: `request_user_input`; numbered-list fallback otherwise). This answer
+   the moment it lands and get a keep-or-change answer through your question
+   tool (a short numbered list in chat when you have none). This answer
    GATES — but only the style-dependent pipeline: until the user approves a
    frame, do NOT enqueue the Tier-2 art that builds on the look (the
    `$genex-ai-hud` Stage-2 chain, and the `$genex-ai-menu` still + video
@@ -58,10 +99,10 @@ Three.js release or branch, and do not blindly copy demo architecture.
    arrive, and later `--edit`-able generations anchor to the approved frame for
    STYLE while the game contract owns content. Everything that does NOT depend
    on the look — scaffold, boot wiring, the core loop, and the
-   concept-independent content subagents below — keeps building in parallel
-   while the answer is pending, so the wait is never idle. Skipping this enqueue is
-   the #1 way a finished game ships an ugly HUD — by step 12 there is nothing
-   to swap in.
+   concept-independent worker lanes (the director's Delegate section) —
+   keeps building in parallel while the answer is pending, so the wait is
+   never idle. Skipping this enqueue is the #1 way a finished game ships an
+   ugly HUD — by step 12 there is nothing to swap in.
 4. Lock the visual direction — the same plan-first logic as the UI gate, in
    the same plan block, before any rendering code:
    - **camera**: the rig type and the pointer bucket
@@ -144,7 +185,7 @@ Three.js release or branch, and do not blindly copy demo architecture.
      Emissive-only is a real answer said in one line; a coupled practical
      light is the step up; one white ambient wash over everything is the
      unlit look with extra steps, and it reads the same at noon and at
-     midnight. `$genex-threejs-lighting-design` owns this gate;
+     midnight. `$genex-threejs-lighting-design` owns that gate;
    Planning is not building: effects still land LAST (steps 10–11); this step
    only fixes the target so the look isn't improvised pass-by-pass at the end.
 5. Wire the gameplay layer for the player verb: the physics world via
@@ -217,61 +258,23 @@ 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 — the default whenever the environment has them
-
-Generations already render server-side in parallel — the wall-clock savings
-live in the ATTENDED chains. Whenever the coding agent supports background
-subagents (e.g. Claude Code's Agent tool), fanning the independent work out is
-the DEFAULT, not a big-scope special case: split every disjoint chain below off
-by default and keep the main thread building. In environments without them
-(Cursor), the same order simply runs sequentially and the `--no-wait` pattern
-still hides most generation latency.
+## Delegation
 
-**One ordering rule from the concept gate (step 3):** subagents that build ON
-the look are CONCEPT-DEPENDENT and wait for the user's keep/change yes — the
-HUD chain worker and any style-matched art. Subagents that do NOT depend on the
-look — the content-module fan-out, verification of concept-independent parts —
-launch immediately and run while the concept answer is still pending. Never let
-the pending yes stall concept-independent work, and never fan out
-concept-dependent work before it.
+Fan-out is owned by the director: sub-agents own DESIGN.md Modules rows,
+concept-DEPENDENT lanes wait for the player's yes on the concept, one writer
+per file, workers never spawn workers, and the Assets table is the budget —
+the full rules and the worker prompt shape live in the Delegate section of
+`$genex-game-director`. This map adds no separate delegation rules; it is the
+routing source the director and its workers read.
 
-- **HUD chain worker (concept-dependent — starts on the yes).** The moment the
-  user APPROVES the concept, 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, the approved mockup URL, the
-  output dir, and exactly which files it owns. **Handoff rule:** whoever
-  wires the HUD after the subagent finishes MUST read the produced
-  `*.annotated-progress.json` and `.bbox.json` files from disk — fillBox
-  numbers, `segments`, and sprite dims do not survive a prose summary, and
-  wiring from the summary is how validated masks end up on disk while the
-  shipped fill is a naive width%.
-- **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.
-- **Content module fan-out (big scopes — concept-independent, launch immediately).**
-  When the content contract names a
-  big world or several content systems, serial hand-typing is what runs out
-  of session: split the gameplay modules across parallel subagents instead —
-  one each for world/terrain, quest + dialogue DATA, enemies/AI, items/
-  economy — against a short written module contract (the shared state
-  object's shape, the event names, the content tables from
-  `$genex-threejs-game-content`, exact file ownership). Ship the
-  walking-skeleton v0 preview FIRST, then let the content agents land behind
-  it — the preview cadence and a long parallel build are not in conflict:
-  the user walks the skeleton while the world grows. Each subagent reports
-  deviations from the module contract; the main agent reconciles and stays
-  the only writer of the entry point.
+## Routing rules
 
-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.
+- Build silhouette, motion, and material readability before adding image
+  effects. Never dress a primitive shape in glow or bloom to fake quality —
+  authored forms first, then materials, then lighting, then effects last.
+- Keep game logic, simulation state, visual fields, and screen-space passes
+  separated unless coupling is intentional.
+- Prefer deterministic seeds and named controls for every procedural system.
 
 ## Acceptance gate
 

package/templates/skills/genex-getting-started/SKILL.md

@@ -26,8 +26,9 @@ out automatically — only `genex-*`-named files are removed, never yours.
 - **agents/** - example subagent definitions (Claude Code).
 - **commands/** - example slash commands (Claude Code).
 
-Start with `$genex-threejs-skill-router` for broad game or graphics requests.
-It routes the agent to focused skills for cameras, procedural geometry,
+Start with `$genex-game-director` for any game or graphics request. It checks
+what your environment can do, writes the `DESIGN.md` design contract, and
+routes the agent to focused skills for cameras, procedural geometry,
 materials, atmosphere, water, weather, VFX, lighting, post-processing, and
 visual validation.