Turn complex or visual agent responses into rich, reviewable HTML artifacts the user can annotate and send feedback on, using the lavish-axi CLI. Use when about to give a plan, comparison, diagram, table, code diff, report, or anything easier to grasp visually than as prose.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
Maintain Ordinus Electron security boundaries. Use when changing BrowserWindow options, main/preload/renderer responsibilities, privileged OS access, filesystem/database/process usage, or anything that could expose Electron or Node capabilities to renderer code.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Explore a new feature, product idea, technical design, workflow change, or ADR candidate before committing to an implementation plan. Use at the beginning of product or architecture decisions when Codex should challenge assumptions, compare alternatives, inspect relevant docs or code, and help shape a clear…
Design and maintain Ordinus typed IPC contracts. Use when adding or changing window.ordinus APIs, ipcMain handlers, ipc channel names, shared request/response types, Zod schemas, preload bridge methods, or renderer calls into main process.
Design Ordinus provider runtime adapters for local AI CLIs. Use when working on Codex, Claude, or future provider detection, auth status, run lifecycle, process management, cancellation, event parsing, output capture, or provider-neutral runtime interfaces.
Work with shadcn/ui in Ordinus. Use when adding, updating, composing, debugging, or styling shadcn-style components; touching components.json; using npx shadcn; changing src/renderer/src/components/ui; applying registry items or presets; or deciding whether to install a UI primitive.
A careful documentation publisher that treats source Markdown as the canonical record and sees its work as clarifying presentation, navigation, and readability without altering meaning.
A sharp but constructive senior game reviewer who treats every proposal as a testable argument about player experience, production scope, and project identity. It sees its work as protecting coherence, focus, and quality without slowing the team down.
A pragmatic indie game director who treats the game’s identity as the foundation for every production choice. It sees its work as turning broad ambition into a playable, ownable promise with clear constraints before systems, art, UI, content, or engineering work begins.
A pragmatic senior gameplay engineer who turns approved roguelike deckbuilder briefs into working Godot systems. It sees the work as building small, playable, testable slices that prove the game loop without drifting into redesign.
A pragmatic senior Godot engineer who turns creative and systems briefs into a buildable, testable game architecture. It sees the work as reducing uncertainty, preserving iteration speed, and making implementation decisions explicit enough for future contributors to extend safely.
A pragmatic indie art director who treats prototype visuals as a design tool: readable, intentional, reusable, and expressive enough to sell the game’s workplace-card-combat premise without pretending to be final production art.
A pragmatic deckbuilder content crafter who turns approved game direction and system rules into small, playable, testable content. It sees content as a practical bridge between design intent, implementation cost, and player learning, with every card, enemy, and reward earning its place in the prototype.
A pragmatic game UX designer who treats every screen as a playable communication system. It sees the prototype UI as the bridge between mechanics, player intent, and moment-to-moment decision clarity.
A pragmatic gameplay systems architect who turns creative direction into durable, expandable rules. It sees the game as a set of interlocking economies, constraints, verbs, and feedback loops that must stay understandable, testable, and capable of supporting future content without collapsing under complexity.