メニュー
Use when creating or refactoring gameplay code in an Air Jam project and you need guidance on host vs controller vs domain boundaries, modular structure, and when to refactor before implementing.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | game-architecture |
| description | Use when creating or refactoring gameplay code in an Air Jam project and you need guidance on host vs controller vs domain boundaries, modular structure, and when to refactor before implementing. |
Use this skill when adding new systems or moving code between boundaries.
docs/generated/project-structure.mddocs/generated/architecture.mdPrefer this split:
src/airjam.config.ts for catalog metadata plus runtime config such as controllerPath and input schemasrc/app.tsx for mounting explicit host/controller runtime boundariessrc/host/ for host-only compositionsrc/controller/ for controller-only compositionsrc/game/domain/ for pure rulessrc/game/engine/ for orchestrationsrc/game/systems/ for focused gameplay systemssrc/game/adapters/ for framework integrationsrc/game/ui/ for reusable game-facing UIsrc/game/debug/ for debug helpersKeep runtime ownership explicit:
airjam.Host / airjam.Controller once at the boundaryuseAirJamHost() and useAirJamController() only below that boundaryAsk:
Put the code where the answer is clearest.
If new work would harden a mixed boundary, split the structure first or split the task into:
Use when building or reviewing the Air Jam host shell so the active game surface stays full-frame, overlays stay modular, and host UI does not interfere with gameplay layout.
Use when creating reusable gameplay objects or scene presets so prefabs stay declarative, configurable, and ready for future tooling such as previews and scanned catalogs.
Use when building or reviewing Air Jam controller surfaces so touch controls stay simple, readable, and game-appropriate instead of drifting into dense web-app UI patterns.
Use when debugging or validating an Air Jam project so diagnostics, logging, and tests stay intentional, structured, and aligned with the project architecture.
Use when an Air Jam task needs canonical guidance and you need to know which local docs to read, when hosted docs are appropriate, and how to avoid reading the whole docs tree unnecessarily.
Use when building or reviewing a 2D Air Jam game with canvas so simulation, rendering, SVG/sprite assets, scaling, and collision stay clean instead of collapsing into DOM-heavy ad hoc logic.