Game Build Execution

Protect the approved experience boundaries; protect the approved art boundaries during formal production. Drive the implementation model to complete a truly playable candidate, and do not rework concepts, levels, or art directions during the build phase.

Read build-brief-contract.md and playable-model-contract.md.

GAME_DESIGN.md

must be available during the whitebox phase;

ART_DIRECTION.md

must also be available for a complete candidate. When product decisions are missing, refer back to the corresponding owner instead of inventing content locally in the BUILD_BRIEF.

The product language is locked by

PRODUCT_BRIEF.md

; if not locked, follow the conversation language, and do not default to outputting Chinese.

Objectives and Flexibility

Deliver according to the platform, production engine, target runtime, display/input, scope, rating, and networking boundaries locked in the PRODUCT_BRIEF. Do not automatically switch to web development when the target toolchain is unavailable; only use an alternative runtime if it has been approved in the brief, and record

targetRuntime

testedRuntime

, and uncovered items separately.

Formal production inherits the brightness boundaries of the art direction. For non-low-light themes, do not arbitrarily use global black masks, vignetting, reduced exposure, or low-contrast small text to create a "cinematic feel" during the implementation phase; night scenes must also retain the readability of characters, objects, actions, and results. If a dimmer interface is truly needed, implement it only within the approved scope, and retain the brightness or high-contrast fallback agreed in the direction.

For high-risk art styles of era-themed projects, first integrate an actual target image and confirm it in the target viewport before mass production. After the target image is approved, subsequent assets must inherit the same era world, expression medium, character maturity, identity anchor, light color, and text whitespace; do not arbitrarily implement "contemporary aesthetics" as modern clothing/studio photography, nor implement "ancient style" as aged ancient paintings. When the user rejects the direction, stop mass production, replace runtime references, and clean up rejected assets; do not mix old images, test images, and approved images in the same release package.

BUILD_BRIEF only compresses product boundaries, experience facts that must be preserved, operation methods, and completion evidence; implementation details are left to the implementation model.

First declare

buildStage: whitebox|production

and

buildPath: template|custom

. Existing interaction syntax is only adopted if it can retain the unique actions, costs, and world responses of the original work; core verbs that cannot be covered by real-time feel, space, line of sight, physics, or templates follow the custom path. The whitebox must also choose a form that can verify the greatest risk, and cannot reduce all projects to text-based games.

Implement directly when the current session can be encoded; only deliver build instructions when external models are unavailable, and do not claim the game has been generated. Do not send complete copyrighted original texts unrelated to the prototype.

Read Optional Contracts by Capability

When the voice strategy is not
```
none
```
, read tts-production-contract.md. TTS prioritizes generating local assets during the build phase; runtime remote synthesis must be approved in the brief, and keys are only stored on trusted servers.
When dynamic media is actually used, read generative-media-pipeline.md. When approved reference images are available, constrain by the images; tools and models are selected according to the current environment, and not written as cross-project defaults.

Collaborative Build Cycle

First implement a minimal but complete core loop: launch, real input, state change, result, and restart. When the scope is insufficient, revise the scope instead of first accumulating audit materials.
First focus on implementing the minimal state surface and rule adjudicator, then connect the presentation layer. The model can interpret free input, propose candidate actions, or write dialogue based on submitted results; only the rule adjudicator can submit resources, positions, knowledge, commitments, object ownership, wins/losses, and event logs. When the design includes
```
signature_command
```
, first inherit
```
id / label / intents / slots / validators / commit
```
verbatim, and the pipeline is fixed as "expression → versioned candidate structure → schema/precondition/knowledge/commitment verification → execution resistance → deterministic submission → narration"; ambiguous, conflicting, or out-of-bounds candidates return clarification/rejection and are not submitted, and keyword hits or model
```
effects
```
cannot directly modify the state.
Fix the content/rule/save version, initial state, seed, and input sequence; the event log records action, observer, and summary of before-and-after states. Exclusive commands also record parser version, standardized candidates, verification results, execution traces, and due items; replay consumes recorded candidates instead of re-invoking online models. Playtest feedback is located to nodes, and after local patching, replay failed paths and adjacent counterexamples, and do not allow unselected branches to enter the history.
Write back the actual toolchain, install/build/start commands, and versions; write
```
NOT_AVAILABLE: reason
```
for unknown values instead of guessing.

For

whitebox

, only run the narrowest model/replay checks and startup smoke tests, output structured observations, and hand them back to the design owner; do not call

game-qa

, write or overwrite

qa/verification.json

, nor pass off whitebox approval as completion of a production candidate. After design revisions, replay affected paths until the greatest risk has been actually exposed or the current direction is rejected.

For

production

, continue with the following steps:

Provide an authoritative verification command and minimal observable state, enabling
```
game-qa
```
to complete
```
clean start → core action → design result → restart
```
in one go; do not pre-write QA conclusions or repeatedly run full acceptance during the build phase.
Run the narrowest development checks and startup smoke tests, fix build failures, blocked logs, resource failures, and crashes; items related to target platform input, performance, packaging, or devices not covered by the alternative runtime are written into limitations.
Reach the
```
targetFinish
```
specified in the brief; higher completion only handles approved focus assets and signature moments, and does not create release audits unrelated to the playable closed loop.
Hand over to
```
game-qa
```
to run the authoritative command only once and write final facts. If time, budget, or generation calls are exhausted, only FAIL/NOT_RUN will be left, and PASS will not be generated.

Continuous 3D, voice, generative media, multilingual support, and accessibility only add project-specific regression checks when actually adopted. Required asynchronous asset loading or decoding failures cannot silently switch to graybox while claiming approval; fallback conditions for continued operation are specified in build-brief-contract.md.

Output

Generate

build/BUILD_BRIEF.md

and the actual candidate; production also generates an authoritative verification entry. The build phase does not generate final QA conclusions.

Screenshots, recordings, and raw traces only retain the minimal set required for debugging;

game-qa

is the sole owner of the production complete path and

qa/verification.json

game-build

NPX Install

Tags

SKILL.md Content (Chinese)

Game Build Execution

Objectives and Flexibility

Read Optional Contracts by Capability

Collaborative Build Cycle

Output