Xian55

Add or change a player input action (a key/mouse-driven control) the right way — routed through the rebindable input action map, never a hard-coded key. Use whenever you introduce a new control (a new key/button the player presses) or change how an existing control is read, so it stays rebindable via keybindings.cfg.

Build and run the Adventure headless unit-test suite (doctest via CTest). Use after changing anything in adventure_lib (Lua engine, metrics, systems) to check for regressions before committing.

Authoritative reference for the TrenchBroom/Quake Valve 220 .map format and Adventure's map conventions. Use when authoring, generating, editing, debugging, or validating a .map file, or wiring TrenchBroom to the project. TrenchBroom has no MCP server or CLI/scripting API — .map is plain text, so we generate/validate it ourselves (parser: src/world/MapParser).

Bootstrap a new contributor (or a fresh machine) into the Adventure project — install the toolchain, set environment variables, build, and verify everything works. Use when someone is setting up the project for the first time, or when a clean-machine setup / environment problem needs fixing.

Produce/export game sprites (billboard atlases, viewmodels) with Aseprite via the ASEPRITE env var, so scripts stay machine-independent. Use when creating or batch-exporting sprite sheets, or setting up Aseprite CLI automation for the asset pipeline.

Keep the project's documentation current after a code change — the subsystem CLAUDE.md files, the root CLAUDE.md, and docs/design. Use at the end of any feature or structural change (it's the final step of adv-feature), or whenever architecture, commands, conventions, or milestone status shift.

The end-to-end harness for building a requested feature in Adventure autonomously — design it, implement it under SRP, test it thoroughly, gate it on performance, verify it, and commit. Use this whenever the user requests a new gameplay/engine feature (a system, mechanic, weapon, enemy, level element, etc.) rather than a trivial fix. It defines the required steps and quality gates so the work is reliable and doesn't regress performance.

Apply or check the Adventure C++ house style with clang-format. Use before committing C++ changes, or when CI's format gate fails. Formats src/tests/bench per .clang-format (tabs, Allman, ColumnLimit 0); never touches vendored deps/.

The end-to-end harness for building a requested feature in craft autonomously — design it, implement it, test it, gate it on determinism + performance + memory, verify it renders, update docs, and commit. Use whenever the user requests a new gameplay/engine feature (a block, item, mob, mechanic, fluid, UI panel, protocol message) rather than a trivial fix. Defines the required steps and quality gates so the work is reliable and doesn't regress.

Build and run craft's full headless test battery — the terrain determinism gate, the phys/sim/net unit exes, the server self-test, the live-wire e2e, and the bench_test perf+memory gate. Use after changing anything in src/ to check for regressions before committing. All must stay green.

craft's Release-only micro-benchmark + memory harness (bench_test.exe). Use when adding or changing a hot path (gen, mesh, light, fluids), setting a CPU or memory budget, or investigating a ms/allocation regression. Run it before commit as the perf+memory gate; complements CRAFT_PROF (whole render loop) and the F3 metrics overlay (live).

Build the native craft client, run it headless, and capture an in-game screenshot to visually confirm a rendering or gameplay change looks right (not just that it compiled). Use when asked to build and run, screenshot the game, or verify a change on screen. Drives the built-in CRAFT_SHOT one-shot screenshot hook and the CRAFT_POS/TIME/CMD scene-staging hooks.

Keep the project's documentation current after a code change — the root CLAUDE.md and the memory/ dir. Use at the end of any feature or structural change (it's the final step of craft-feature), or whenever commands, architecture, conventions, gotchas, or machine/deploy facts shift. Keep everything lean — CLAUDE.md loads into context every session.

Scaffold a new single-responsibility C module (header + source) in src/, wired into the craft target and any test/bench exe that needs it, following craft's style and build conventions. Use when adding a new system or subsystem so it follows the project's SRP, C11 style, and CMake wiring.

Bootstrap a new contributor (or a fresh machine) into the craft_raylib project — install the toolchain, build, and verify everything works. Use when setting up the project for the first time, or when a clean-machine setup / environment problem needs fixing. Windows is the primary target.

raylib 5.5 API reference, version-exact for this repo's pinned build. Use when writing or modifying rendering, window, input, texture, mesh, shader, audio, raymath or rlgl code — grep the references for exact signatures instead of recalling them from memory (raylib's API shifted between versions; this matches OUR raylib).

Run Google Lighthouse over the Tortoise-WoW DB viewer's rendered pages and read the results for THIS site (a no-backend SPA that ships the whole SQLite DB to the browser). Load whenever asked to audit / profile / Lighthouse the site, check performance / accessibility / best-practices / SEO of a page, measure Core Web Vitals (LCP/TBT/CLS), or investigate why a page loads slow or scores poorly. Runs `bun run audit` (scripts/audit.mjs) — boots `vite preview` and drives Lighthouse via a fresh headless Chrome. Covers how to run + filter routes, the representative route set, and — the real value — how to interpret scores given the whole-DB (sqlite-wasm/OPFS) architecture: the intentional cold ~13 MB DB download structurally caps perf, so a11y / best-practices / SEO are the actionable levers. Triggers: "audit the site", "run lighthouse", "check performance", "check accessibility", "web vitals", "why is <page> slow to load", "lighthouse score".

SQLite performance for THIS project — a read-only, CI-built, browser-side (sqlite-wasm + OPFS) database. Load whenever touching scripts/build-db.mjs, src/queries.js, src/db-worker.js, index or schema design, the shipped file size / download, WASM cold-load time, FTS/search, or ANY slow-query / EXPLAIN QUERY PLAN investigation — even if the user never says the word "performance". Covers build-time schema+indexing, runtime WASM pragmas, and reading query plans. Does NOT cover the SQLite write path (WAL, locking, pooling, transactions) — this DB is never mutated in the browser; see references/not-applicable.md.

Rules for adding or editing a DERIVED table / relation in the DB build (scripts/build-db.mjs, scripts/lib/*, or any build-time SQLite derivation that reads staged/imported tables to compute a new viewer table). Load BEFORE writing derivation code that joins large tables (drops ~550k, spawn_points ~160k, creatures ~30k) or loops over entities/maps/zones running a query per iteration. Enforces set-based (index-free-safe) derivation and dataset-agnostic relations so the build stays fast and works across every dataset (Turtle main, 1181dev, cmangos vanilla). Triggers: "derive a table", "new build-db table", "quest_dungeon-style", "build is slow/hanging", "add a relation", "cross-entity link at build time".