メニュー
Use when designing game client, authoritative state, engine integration, content, saves, multiplayer backend, platform adapters, telemetry, security, build, and live-operations architecture from an approved game SRS.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when defining a game's player promise, product hypotheses, platform options, production model, vertical-slice evidence, commercial boundaries, or greenlight decision before detailed requirements.
Use when specifying testable game software requirements for player experience, gameplay state, platforms, multiplayer, saves, content, performance, accessibility, telemetry, security, builds, release, or live operations.
Use when turning approved game requirements and architecture into implementable Unity, Godot, Unreal, Apple-native, multiplayer, content-pipeline, build, and telemetry work packages with code and asset contracts.
Use when planning game QA, playtesting, balance, deterministic simulation, save migration, multiplayer network conditions, device performance, accessibility, localisation, security, certification, and release-candidate evidence.
Use when documenting reproducible game builds, signing, artifact promotion, distribution, staged rollout, rollback, crash diagnosis, matchmaking operations, live events, remote config, economy controls, support, or incidents.
Use when assembling or reviewing game greenlight, milestone, release, rights, security, player-research, build, test, live-operations, and independent-replication evidence without inflating capability claims.
| name | 17-game-system-architecture-specification |
| description | Use when designing game client, authoritative state, engine integration, content, saves, multiplayer backend, platform adapters, telemetry, security, build, and live-operations architecture from an approved game SRS. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
| Artefact | Source or provider | Required? | Behaviour when missing |
|---|---|---|---|
GREQ-*, engine/platform decision, topology, budgets and risks | Requirements, architecture and production | Yes | Stop and return unresolved decisions. |
| Plugins, platform services, data and threat constraints | Specialist owners | Conditional | Mark integration provisional. |
design-system-skills.| Artefact | Consumer | Acceptance condition |
|---|---|---|
| Game architecture and ADRs | Implementers, QA, security and operations | State, interfaces, failures, budgets and traces are reviewable. |
| Evidence | Reviewer | Acceptance condition |
|---|---|---|
GARCH-* trace and failure model | Architecture board | Each element maps to requirement, ADR, test and signal. |
Read and search are allowed. Provisioning, purchasing or production change requires explicit authority.
Produce the narrowest qualified context, mark unavailable checks not assessed, and name the experiment needed.
| Choice or condition | Action | Failure or risk avoided |
|---|---|---|
| Logic can avoid engine objects | Isolate testable domain code. | Engine coupling. |
| Action originates on client | Validate authoritative state. | Cheating. |
| Schema changes | Version, migrate and test rollback. | Lost state. |