Compositional / recipe-system designer for Yume games. Translates GDD intent for crafting / alchemy / breeding / key-combos / chemistry / spell-combinations into a concrete combining-design.md — recipe table, discovery model, yield rules, failure modes, Yume primitive mapping. Universal pattern (NOT magic-specific) — the underlying shape is "input set + combination rule → output", which appears in dozens of genres.
Run the Yume text-to-game pipeline. Orchestrates 7 specialist skills (yume-game-designer → game-planner → systems-designer → content-designer → asset-designer → qa-tester, plus tech-director on demand) with optional user-approval gates. Skills load into orchestrator context (no subagent spawn — Tier 2.6 architecture). Flags - `--autonomous` skips approval gates and runs end-to-end. `--plan-only` stops after the planning phases (GDD + world-plan) so the user can review before any JSON is committed. `--with-assets` invokes AI-gen pipeline. `--style=pixel-art|low-poly-3d|ascii` art-style hint. `--name=<slug>` game folder name.
Spatial layout designer for Yume games. Reads GDD + world plan, produces level-design.md with concrete coordinates for every placement plus a design rationale per element. Genre-aware patterns (TD paths with chokepoints, shooter arenas with cover, sim zones with density falloff). Output is the single source of truth for content-designer's placement work.
Genre-specific designer for arcade racing games — kart racers (mascot-style kart racer), high-speed (futuristic anti-grav racer), top-down (top-down arcade / top-down combat racer), time-attack (precision time-attack racer), checkpoint runners (arcade crash-racer). Owns the tuning discipline that makes a car FEEL like a car: vehicle profile, steering rate vs speed, drift mechanic, lateral-grip scrubbing, surface variety, AI rubber-banding, power-up taxonomy, race structure, camera. Archetype-driven — every design decision benchmarks against a named racing archetype. Does NOT cover sim racing (dedicated racing simulators) — that needs continuous physics out of Yume's scope.
One-command text-to-3D-world pipeline. From a prose scene pitch, produces a runnable Yume scene end-to-end — hero reference → hero-conditioned orthographic → semantic + heightmap → extract → map (compose_world) → presentation shell (compose_shell) → optional Tripo assets. The catalog is the single LLM-authored input; tools.visual_layout.compose_scene drives the rest deterministically. Invoke when the user wants a whole new 3D scene/level from a description (NOT for HUD/screen authoring, single assets, or GDScript-game generation).
Stage 2 of the text-to-world pipeline (2026-05-25). Reads a scene brief + reference photoreal aerial and produces a fully-dynamic per-scene class catalog plus the stage-3/4/5 prompts. Class count is dynamic 6-32; classes named freely per genre (medieval town vs sci-fi colony vs dungeon vs alien world all get entirely different catalogs). data/lib/semantic_palette.json provides palette conventions; data/lib/extraction_strategies.json provides per-class extraction strategies (extraction_method + rotation_rule + y_anchor + primitive + canonical size) that the catalog injects into each object_placement entry so stage-5 lib_extract can dispatch by name lookup. Outputs class_catalog.json, semantic_map_prompt.txt, heightmap_prompt.txt, and scene_biome_mapping.json (for ADR 0055 engine wiring).
Visual + audio + UI-style designer for Yume games. Picks ONE consistent strategy per project (library lookup / AI-gen prompt / code-draw shape) for visuals; writes audio cue mappings and localized strings. Per ADR 0009 — owns audio/cues.json (semantic event → sound name) and ui/strings.json (localizable HUD text), in addition to entity visual/audio fields and scene/hud config. Doesn't generate raw asset files (.png/.glb/.ogg) — that's the offline `yume assets generate` tool.
Second-pair-of-eyes for Yume engine + content changes. Socratic, principle-aligned, smell-based. Reviews diffs / files / sessions and produces a tight verdict (accept / accept-with-conditions / revise / reject). NOT the invariant gate — that's yume-tech-director. NOT a designer — those are the domain skills. This is the "code reviewer" who asks the questions the user would.