Develop, test, and QA the WorldOS plugin (the living-world D&D 5e engine). Use when implementing an engine/content/QA change, running or scoring a playtest, running the blind AI-playtester GUI harness, delegating a build to a subagent, or resuming the project after a compaction. Encodes the exact dev loop (worktree → additive change → focused single-process pytest → PR → merge → prune), the story/mech QA loop (duo / combat-sprint runners + the 3 lenses + behavioral gate), the GUI QA loop (the
The "Angry-DM for graphics" — WorldOS's recursive self-improving VISUAL feedback loop. Use to SCORE/critique any WorldOS render (a frame from the Unity closed-loop pipeline, the archived Godot extension, or a still) against the **Pillars of Eternity II: Deadfire** painterly bar (BG2 = a tactical-readability cross-check only; Disco Elysium = a dark-pocket/mood cross-check only), and to drive the render→pre-gate→panel→fix→re-render loop until a scene CONVERGES to that bar instead of plateauing. v2: REFERENCE-ANCHORED (the critic scores the GAP to specific named reference frames), a DIVERSE 5-7 lens PANEL (parallel subagents), DETERMINISTIC pre-gates (frame-lit + floor-contact + screen-scale + occupancy + motion-liveness, numbers not vibes), and REGRESSION-TRACKED in scores_db (surface="visual"). v3 re-anchor: PoE2-as-sole-bar; L4 rewarded for a GROUNDED real-3D actor (not a painterly sprite); an L7 MOTION lens scored from a render REEL. Invoke whenever you produce a render and need an honest gap-to-bar score +
Run a D&D 5e session as the Dungeon Master for a WorldOS campaign — narrate scenes, voice NPCs, adjudicate rules, and drive the turn loop. Use when the player starts or continues a WorldOS adventure, enters a scene or combat, or asks the DM to continue. Always sources dice and rules from the worldos-engine and worldos-rules MCP servers (never invents mechanics) and voices lines through worldos-voice.
Generate game art for WorldOS via Meshy / Tripo3D / Scenario / PixelLab — 3D characters, auto-rigging, animation, painterly backgrounds, sprites, tilesets. Use when creating or regenerating visual assets for the active Unity renderer lane, the archived Godot GT2 reference extension, the future GT1 tile engine, or when wiring a non-Eva image-gen provider. Routes the right service to each job and gives the keys, the CLI wrappers, the MCPs, and the sprite-sheet bake contract.
Write a rich handoff / status doc that genuinely transfers knowledge when a multi-PR sprint on a new subsystem will be picked up by a different agent or after a compaction. Use when finishing a sprint, handing off a subsystem, or asked "are we handoff-ready / is this documented for a fresh agent." Produces a HANDOFF.md (diagrams + knowledge base + gotchas + backlog) AND cross-links it from the entry-point docs so it is actually discoverable.
Wire a new external AI/API service (and its MCP) so future agents can reliably use it — secure keys, a CLI wrapper, an optional engine provider, and a service skill. Use when integrating ANY new external generation / API / MCP service (image, 3D, audio, data) that agents will call — storing credentials, registering an MCP, building a wrapper, or adding an image/asset provider. Encodes the probe-auth-first discipline, the key-security pattern, and the subagent-MCP-inheritance gap.
Develop / test / debug the WorldOS GT2 Godot painterly-isometric reference/extension renderer (the `extensions/renderers/godot/` archive). Use only for explicit Godot extension work or a renderer-migration issue that reopens Godot; current isometric/visual-renderer work routes through the Unity/current-renderer and visual-critic lane instead. Encodes the thin-client invariants, the dimetric-2:1 projection, how to run/validate locally, and points at the full knowledge base.
Play the AI companion party member in a WorldOS campaign — a distinct character with its own sheet, personality, and voice who adventures alongside the player. Use when the companion needs to act in combat, react in roleplay, or weigh in on a decision. The DM invokes the companion through the CompanionProvider boundary so it can later be promoted to a standalone OpenClaw sub-session (Tier 2).