菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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.
| name | adv-docs |
| description | 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. |
Docs rot fast. After a change, update what the change touched. Keep everything lean — CLAUDE.md files are loaded into context every session, so they must stay short and scannable.
src/<subsystem>/CLAUDE.md — you added/removed/renamed a file in that subsystem, changed its
responsibility, added a gotcha, or changed how to extend it. This is the primary place detailed
explanation lives (keep it out of code comments).CLAUDE.md — a command changed, a new subsystem/skill was added, a convention changed, or the
milestone status moved.docs/design/ — architecture or a design decision changed (ARCHITECTURE.md), a milestone
completed/reordered (ROADMAP.md), combat/feel rules changed (COMBAT.md), a convention changed
(CONVENTIONS.md), or perf baseline shifted (DEVELOPMENT_LOOP.md).src/<name>/CLAUDE.md (file table + rules + how-to-extend) and link it from the
root layout section.docs/design/.git diff --name-only # which subsystems changed -> which CLAUDE.md need a look