菜单
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. |