IrredenEngine

Review an open GitHub PR on the Irreden Engine repo and post a structured review. Use when the user says "review PR <N>", "review #<N>", "review the last PR", "check my PR", "review any new PRs", "review the PR queue", "check for new PRs to review", "review the open PRs", or otherwise asks for a code review — and also invoke automatically from a persistent reviewer-loop session when `gh pr list` surfaces a PR that has not yet been reviewed by this fleet. Designed to be invoked by a dedicated reviewer agent (dispatched into a pool worktree) whose job is to look at another agent's work with a fresh context. Writes a structured review covering ownership, ECS invariants, allocation hot paths, naming, tests, and project-specific smells, then posts it as a PR comment.

Polish the dirty working tree before committing — catch Irreden-Engine smells that a reviewer would otherwise flag. Use whenever you're about to commit, after addressing review feedback, after amending a commit, or whenever the user says "simplify", "clean up", "polish", "self-review", or "review my changes". Also auto-invoked by commit-and-push before the commit message is drafted. The skill finds per-entity getComponent in tick functions, allocation in hot loops, ECS naming convention slips, opportunities to reuse existing helpers, dead code, debug logs left behind, tautological comments, triple-nested loops over voxel volumes, renderer leaks from creation code, CPU-side SDF grid evaluation, linear-search in save/load hot paths, and stale or drifting CLAUDE.md / role / skill docs. Dispatches a parallel reuse-detection subagent fan-out so the reuse pass runs concurrently with the main checks. Applies safe fixes inline and reports anything that needs human judgment. Saves a review-fix-rereview round-trip.

Stage, commit, push a feature branch, and open a GitHub PR against master for the Irreden Engine repo. Use whenever the user says "commit", "commit my changes", "commit and push", "open a PR", "make a PR", "wrap up this chunk", or otherwise indicates the current slice of work is ready for review. The skill assumes the parallel-agent workflow where work happens on short-lived feature branches, another agent reviews the PR, and the user merges via the GitHub UI. NEVER commit directly to master.

Process the backlog of `fleet:needs-<host>-smoke` PRs on the current host. Builds a representative demo cohort against current `origin/master`, runs each with `--auto-screenshot`, and on green batch-swaps `fleet:needs-<host>-smoke` → `fleet:verified-<host>` on every eligible merged PR. On red (build break), files / opens a fix PR for the offender and holds labels on PRs that touch the implicated source paths until the fix lands. On partial (per-demo runtime hang or crash but build green), sweeps the rest, then fix-forwards the offending demo this session (issue only as the documented fallback). Runs on Linux, macOS, AND native Windows (MSYS2 mingw64) — Windows is now the primary validation host. Use when the human cues "platform-catchup", "catch up smoke tests", or "catch up Windows builds". Skill is **cue-only**, never auto-run — multi-target builds and ~40-demo runs are expensive, the human chooses when to spend them.

Build, run, and visually evaluate a rendering demo in an automated loop. Captures screenshots across a demo's configured shot list (zoom, camera offset, render-mode combinations), reads each image, diagnoses rendering issues against a topic-indexed reference (trixel / SDF shapes, lighting, backend parity), applies fixes, and repeats. Use whenever iterating on render pipeline bugs, shape alignment, lighting, parity drift, or any visual regression in the engine.

Automated pass/fail render-regression harness for Irreden Engine demos. Wraps build → run → capture → compare → report: builds a demo, runs it with `--auto-screenshot`, then compares each shot against a committed reference image using a stdlib-only Python comparator. Reports per-shot pass/fail with diff images written for mismatches. Use after any render pipeline change to catch visual regressions automatically, or as a sanity pass on `master` before cutting releases.

Capture before/after screenshots for an engine rendering PR and commit them to `docs/pr-screenshots/<branch>/` so the PR body can embed them via raw GitHub URLs. Runs an auto-screenshot-capable demo (default `IRShapeDebug`) once against origin/master and once against the dirty working tree — or, in `--two-ref` mode, between two committed refs for the feedback-AMEND path — pairs the outputs by shot label, and prints a markdown snippet the worker pastes into the PR body. Invoke when a PR touches `engine/render/`, `engine/prefabs/irreden/render/`, any `.glsl`/`.metal` shader, or `creations/demos/*/src/`, so reviewers can see the visual delta without running the executable themselves.

Profile and improve performance for newly written or modified performance-critical code in the Irreden Engine. Use whenever the current change touches a system tick function, a render pipeline stage, a shader, audio/video processing, math hot paths, or anywhere on the per-frame critical path. Also use when the user says "optimize", "profile", "this is slow", "find the hotspot", "check perf", "benchmark this", or "why is this frame slow". Should run BEFORE simplify when the change is performance-relevant — optimize may add profile blocks or comments that simplify would otherwise consider extraneous. Reports CPU profiler findings and, where GPU profiling infrastructure exists, GPU timer query results. Files an issue if the necessary profiling infrastructure is missing.

Take an approved architect plan and file it as the fleet expects: umbrella issue labeled fleet:epic, one child fleet:task per phase, per-ticket plan files at ~/.fleet/plans/issue-<N>.md, and post-filing stack validation.

Behavioral GUI test harness for Irreden Engine creations. Builds a creation, runs it headless with the P3 GUI-test shot table, parses per-assertion PASS/FAIL from the result log, and exits non-zero on failure. Use after any GUI interaction change (hover routing, click dispatch, picking) to catch behavioral regressions without a human in the loop.

Drain the fleet:coding-improvement backlog in one human-cued batch: sweep the open tickets, cluster them by target surface, triage each with the human (accept / reject / defer / escalate a doc rule into a simplify check), apply the accepted convention changes, and bundle them into one PR per run with Closes lines — never one micro-PR per ticket. The consumption side of the channel assess-coding-improvement files into. Use when the user says "triage coding improvements", "absorb the coding-improvement backlog", "work through the coding-improvement tickets", or "address the coding improvements". Cue-only — NEVER auto-run: the tickets target gated self-config (role docs, skills, review checklists) and stay un-queued precisely so a human spends the judgment; this skill is how that judgment gets spent.

After fixing PR review feedback, assess whether the fix reveals a generalizable improvement to the fleet's development procedures (style guide, coding rules, simplify checks, review criteria, worker direction) and, if so, file or append to a fleet:coding-improvement ticket. Auto-invoked as the last step of a feedback AMEND (see FLEET-FEEDBACK-HANDLING.md Step i). Also use when the user asks "should this be a fleet rule?", "assess coding improvement", or "file a coding-improvement". It is a reflection pass — it never touches the PR's code, labels, or claim.

Reset the current worktree to a fresh feature branch for the next chunk of work. In the standard case that means branching off the latest origin/master; if the worker has an active fleet-claim molecule (fleet stack mode) or the human cued cursor-flow stacking, the new branch instead bases on the just-opened PR's head ref so the downstream task's diff stays isolated. Use after commit-and-push has opened a PR and the user (or you) wants to move on to the next task, OR whenever the user says "next task", "start next", "move on", "pull master and start fresh", "I merged it", "back to master", "fresh start", "new task", or cues stacking with "stack this", "next slice stacked", "keep stacking", "stack the next on this PR".

Keep the OpenGL (Linux/Windows) and Metal (macOS) render backends functionally in sync. Scans for graphics-backend deviations — shaders, backend C++ sources, render-impl wiring — and ports the missing side so both backends stay at feature parity. Primary direction is OpenGL → Metal (most new work lands as GLSL first), but it also handles Metal → OpenGL when Metal is the leading side. Builds and tests the lagging backend before opening a PR. Use when the user says "metal parity", "port to metal", "sync the backends", "audit render parity", or after a render PR lands that touched only one backend.

Read agent-to-human feedback files (~/.fleet/feedback/<role>.md), cluster recurring snags into patterns, draft concrete fix proposals (which role doc, script, or setting to change), and run a closed-loop check that previously proposed fixes have stopped recurring before declaring them done. Reads everything newer than ~/.fleet/feedback/.last-reviewed, tracks proposed/applied/recurring/closed fixes in ~/.fleet/feedback/.fix-log.jsonl, then bumps the marker on completion so the same entries don't resurface. Use when the user says "review fleet feedback", "check fleet snags", "summarize fleet feedback", "what has the fleet been complaining about", "any new fleet snags", or after a stretch of autonomous fleet activity when the human wants to absorb the backlog. Do NOT invoke proactively — only on explicit ask.

Auto-grow a demo or creation by scanning available engine systems and proposing/applying additive changes to make it more visually impressive. Use when the user says "increase complexity", "make more impressive", "add more systems", "make number go up", "make it fancier", "add more to this demo", or "auto-grow this demo". Also use when the user specifies a concrete enhancement: "add particles", "add animation", "add lighting", "add more entities". Never removes existing features — additive only.

Work with the Irreden Engine render pipeline: voxel-to-trixel stages, canvas textures, trixel compositing, framebuffer output, shaders, camera, and coordinate systems. Use when the user wants to modify rendering, add shader stages, work with canvases, adjust camera/viewport, or understand the isometric projection math.

Scaffold a new Irreden Engine creation (demo, editor, or game) with all required files: CMakeLists.txt, C++ entry point, optional Lua wiring, and pipeline registration. Use when the user wants to create a new project, demo, editor, or game within the engine.

Work with the Irreden Engine render pipeline: voxel-to-trixel stages, canvas textures, trixel compositing, framebuffer output, shaders, camera, and coordinate systems. Use when the user wants to modify rendering, add shader stages, work with canvases, adjust camera/viewport, or understand the isometric projection math.

Run a mid-session quality checkpoint without committing. Mirrors the pre-commit phase of `commit-and-push` (simplify the dirty tree, verify the build for the touched target) but stops before any git operations — no staging, no commit, no push, no PR. Use when the user says "checkpoint", "polish for now", "verify what I have", "clean up but don't commit", "self-review without shipping", "polish + verify", or otherwise wants confidence that the working tree is clean and the build is green before continuing to iterate. Designed for the Cursor / human-in-the-loop flow where intermediate quality passes happen often but PRs open rarely. When the user is ready to PR, they invoke `commit-and-push` as usual; running both back-to-back is fine because `simplify` is idempotent.

Set up Lua scripting for an Irreden Engine creation: bindings, component packs, config files, script wiring, and Lua-defined components/systems via the codegen (build-time C++) or EVAL (runtime LuaJIT) path. Use when the user wants to add Lua support to a creation, register Lua bindings, expose components to Lua, define new components/systems in Lua, or compose pipelines from Lua.

Create new ECS prefabs (components, systems, commands) for Irreden Engine following established conventions. Use when the user wants to add a new component, system, or command, or asks about ECS prefab structure and patterns.

Create MIDI scenes, sequences, and music-driven visualizations in Irreden Engine. Covers MIDI components, systems, outbound pipeline, contact/periodic triggers, Lua MIDI API, and music theory helpers. Use when the user wants to set up MIDI output, create musical sequences, build audio-reactive entities, or work with the audio/MIDI subsystem.

Push changes on the current PR branch and request a fleet re-review. Use when the user says "request re-review", "push and re-review", "push for re-review", "I'm done with this PR have the fleet re-review", or "update PR and get it reviewed again". Also useful when the user has manually edited a PR branch in any pane and wants the fleet review pipeline to pick it back up.

Set up Lua scripting for an Irreden Engine creation: bindings, component packs, config files, and script wiring. Use when the user wants to add Lua support to a creation, register Lua bindings, expose components to Lua, or work with config.lua/main.lua scripts.

Build, run, and visually evaluate a rendering demo in an automated loop. Captures screenshots across a demo's configured shot list (zoom, camera offset, render-mode combinations), reads each image, diagnoses rendering issues against a topic-indexed reference (trixel / SDF shapes, lighting, backend parity), applies fixes, and repeats. Use whenever iterating on render pipeline bugs, shape alignment, lighting, parity drift, or any visual regression in the engine.

Scaffold a new Irreden Engine creation (demo, editor, or game) with all required files: CMakeLists.txt, C++ entry point, optional Lua wiring, and pipeline registration. Use when the user wants to create a new project, demo, editor, or game within the engine.

Create MIDI scenes, sequences, and music-driven visualizations in Irreden Engine. Covers MIDI components, systems, outbound pipeline, contact/periodic triggers, Lua MIDI API, and music theory helpers. Use when the user wants to set up MIDI output, create musical sequences, build audio-reactive entities, or work with the audio/MIDI subsystem.

Create new ECS prefabs (components, systems, commands) for Irreden Engine following established conventions. Use when the user wants to add a new component, system, or command, or asks about ECS prefab structure and patterns.