Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
{"force_route":true,"triggers":["large GM implementation","large GM feature","multi-system GM feature","multi-wave GM program","GM systems overhaul","CPU systems harmony","Auto Book multi-system improvement","delegated GM systems program","large 5 Star Booker GM feature"],"not_for":"Small isolated GM bugs, copy/style changes, one focused test failure, isolated data corrections, or one-file local behavior with no new authority, cross-system data flow, version envelope, or release wave. Use quick, the target project-context skill, or the focused testing/review skill.","pairs_with":["game-design","feature-lifecycle","workflow","verification-before-completion"],"complexity":"Comprehensive","category":"game-development"}
GM brilliant implementation
Run large 5 Star Booker GM programs from current-state evidence through design,
implementation, exact live release, and player-feedback closure. This skill is
a thin control plane. It sequences existing expertise and preserves artifacts;
it does not replace project doctrine, game design, implementation, or deploy
owners.
Instructions
Apply the applicability gate, load authority in the required order, then run
the seven canonical phases and all 34 runtime stages under their declared
dependencies and gates.
Applicability gate
Use this workflow only when the request is GM work and at least one condition is
true:
Two or more player-facing or simulation systems change in one coordinated
release.
Delegated or automatic CPU authority changes across resources, promises,
policies, deadlines, or attention.
The work is explicitly multi-wave.
Authority or versioned data flow changes across backend, frontend,
persistence, and release surfaces.
A single word such as GM, CPU, simulation, or 5 Star Booker does not
qualify. Route a small isolated fix through quick, the target project-context skill, or the
specific test/review skill.
Required loading order
Before a run, read:
The target repository's complete governing instructions.
Its project-local GM implementation skill, when present.
Its project-local GM UI skill before UI, copy, or mobile decisions.
The available account or target-local project-context skill for repository
and release context.
Verify graph, hashes, dependencies, and applicability before progress
Create or validate checkpoints, envelope, approval, or ledger
references/stage-contracts.md
Use the exact orchestration schemas and allowlists
S09 finds delegated or automatic systems
references/cpu-systems-harmony.md
Apply all ten canonical obligations once through the versioned CPU artifact
Enter testing, review, staging, production, or live verification
references/quality-gates.md
Preserve focused, adversarial, release, and exact-live gates
Operator contract
The operator sees seven canonical phases:
ADR -> RESEARCH -> COMPILE -> PLAN -> EXECUTE -> VALIDATE -> OUTPUT
The coordinator executes the 34 runtime stages underneath them. Status reports
show canonical phase, active stage, owner, evidence, next action, and safe resume
point. Do not make the operator manage the raw graph.
Phase 1: ADR and authority
Run these stages in dependency order:
Stage S01: Authority and current state
Load repository authority, working-tree state, current live/release state, prior
artifacts, and the explicit scope. Record evidence as observed, documented,
measured, or inferred.
Gate: Authority, branch/worktree, current state, and scope are unambiguous.
Phase 2: RESEARCH and player truth
Run or reuse current evidence for:
Stage S02: Player evidence
Stage S03: Core-loop extraction
Stage S04: Player psychology and Fogg
Stage S05: Attribution audit
Stage S06: Choice and stakes
Stage S07: Progression and economy
Stage S08: Era, privacy, and trust
Stage S09: CPU system inventory
Stage S10: CPU conflict matrix
Stage S11: CPU one-brain/two-hands parity
Stage S12: CPU precedence and promise/policy preservation
Stage S13: CPU failure, receipts, and control transfer
Stage S14: CPU cross-system simulation and player-feeling review
Use game-design for the complete player-path method. For S03, S04, and S05,
load Core Loop Extractor, Fogg Behavior Audit, and Attribution Audit packets.
Use cpu-systems-harmony.md for S09-S14.
If S09 proves there is no CPU scope, S10-S14 may become not_applicable only
through the exact predicate and audit contract in the pipeline spec.
Gate: The evidence inventory, player loop, design risks, and every applicable
CPU obligation have a verdict, owner, and disproof or test route.
Phase 3: COMPILE the implementation contract
Run:
Stage S15: ADR and version envelope
Stage S16: Architecture and data flow
Stage S17: Simulation, determinism, and CPU-ignore path
Stage S18: Mobile-360 information architecture
Stage S19: Distinctive visual design
Stage S20: Accessibility and reduced motion
Stage S21: Copy and anti-AI editing
Stage S22: Analytics and KPI guards
Use one short active decision ADR per wave or system. Bind architecture to
architecture-deepening, visual work to distinctive-frontend-design, copy to
the target's anti-AI editing method, and UI behavior to the target's GM UI
doctrine plus its vanilla-JS game frontend method when available. The implementation envelope and
ledger contain coordination facts and links, never architecture rationale or
future authorization.
Gate: The versioned contract has single writers, typed flows, deterministic
simulation, mobile/accessibility behavior, player-facing presentation, and
benefit plus welfare metrics.
Phase 4: PLAN the wave
Stage S23: Wave and worktree plan
Use feature-lifecycle, planning, and subagent-driven-development to map
dependencies, file ownership, isolated worktrees, integration order, focused
tests, rollback, and release evidence. Parallel lanes must not write the same
file. Backend and frontend applicability comes only from S16's deterministic
surface map; at least one lane must run.
Gate: Every task has one owner, inputs, outputs, tests, stop rule, rollback,
and a conflict-free integration edge. Name exactly one integration and deploy
coordinator for the whole active release train. Parallel waves may prepare
commits, but they may not stage or deploy independently.
Phase 5: EXECUTE and converge
Run:
Stage S24: Backend implementation
Stage S25: Frontend implementation
Stage S26: Integration
Use test-driven development where behavior changes. Each lane commits only its
owned files. Converge in one clean integration branch/worktree, preserve user
changes, and reject stale-input checkpoints. A conditional lane may skip only
with the declared false predicate and a complete audit record.
Before S26 completes, the integration owner rereads the live SHA, inventories
every ready wave commit, and rebases or cherry-picks the accepted set into one
clean candidate. Record included and deferred commits, then validate the
complete ready-artifact closure. A commit name or cherry-picked tip is not
closure proof. For every ready artifact, compare the candidate with its
declared prerequisite commit closure and either its exact file-set/content hash
or its full source-diff hash. Reject a candidate that omits a prerequisite
parent's files or state, even when a later child commit applies cleanly. A ready
parallel wave cannot start a competing release from the same or an older live
base.
Gate: The integrated commit implements the accepted envelope, preserves the
CPU-ignore path and project doctrine, and contains no unrelated files.
Phase 6: VALIDATE and release
Run:
Stage S27: Focused tests
Stage S28: Adversarial perspective, system, and security reviews
Stage S29: Predeploy game-design gate
Stage S30: Emergency staging
Stage S31: Staging verification
Stage S32: Production deployment
Stage S33: Exact live verification
S28 fans out independent parallel-code-review, multi-persona-critique,
system, integration, and security-review lenses, then converges findings.
S29 applies Core Loop Extractor, Craft Critique, Attribution Audit, and Fogg
Behavior Audit to the implemented moments and fixes concrete misses before
release. Use only the target repository's supported deploy and rollback paths.
Before S30, the named integration owner must acquire the target project's
deploy coordinator/lock and emit the deploy-lease record defined in
stage-contracts.md. The owner then rereads the
live SHA, collects all ready accepted commits, rebuilds one clean integration
candidate when the base changed, and broadcasts the candidate SHA and lease.
Only that owner may run staging or production while the lease is active.
Reject concurrent attempts, a stale base, an unlisted ready commit, a candidate
SHA mismatch, an expired lease, an incomplete ready-artifact/file-set closure,
or a lock the project cannot prove it holds. Recompute the candidate closure
after any integration conflict resolution and immediately before staging.
Release the lease only after exact-live verification or completed rollback.
Explicit owner authorization or a valid fast-development approval record can
satisfy the approval question without another pause. It never disables branch,
privacy, test, rollback, deploy, exact-SHA, service, health, asset, or route
guards. See quality-gates.md.
Gate: Production serves the exact intended SHA; services, health, assets,
routes, and authorized contracts are verified, with rollback evidence present.
Phase 7: OUTPUT and learn
Stage S34: Feedback, retro, and completion ledger
Collect a privacy-safe post-live delta, distinguish new regressions from prior
feedback, retain every valid unfinished item, record metric and welfare guards,
and run retro. Report exact live SHA, evidence, decisions, changes, tests,
release proof, feedback window, and next wave.
For conditional defects and human/volume-dependent evidence, use the binding
incident and evidence-disposition records in references/stage-contracts.md.
Never turn a zero-volume signal, an unreproduced report, or an unmet research
threshold into speculative product work. A severe repair-now lane opens only
after the exact-state reproduction record proves its trigger, except for an
actively observed production emergency where containment is the narrowest safe
action and the record is completed during containment.
Store every threshold once in the run's canonical evidence-gate registry.
Disposition records and the bounded consumer manifest cite the registry hash
and row IDs without copying threshold fields. Narrative reports link to a
validated consumer receipt; the validator does not parse arbitrary prose.
Before closure, emit one canonical
completion snapshot after the append-only history and validate that its row
counts exhaust the scope exactly. A later release replaces the current snapshot
and links the prior snapshot; it does not add another competing authority block.
Runs resumed from a pre-1.1 checkpoint must rerun S34 and emit the 1.1 registry,
scope, disposition, and snapshot-manifest artifacts before completion.
Gate: The ledger is complete, narrow, hash-linked, honest about every
unfinished or unmeasured claim, and every conditional row has a machine-checkable
trigger plus refusal disposition. The canonical snapshot and reference-only
consumer manifest validate. The run is complete.
Checkpoint and resume pattern
After every stage, write the stage contract from
stage-contracts.md: input/output hashes, owner,
status, attempt count, applicability audit, and rollback pointer. Resume only
when the spec and inputs still match. Retry a failed stage at most three times;
otherwise stop with preserved evidence and a concrete next action.
Preferred patterns
Prefer
Avoid
Existing skill owns method; this skill owns handoff
Copying domain checklists into this skill
One short ADR per active wave/system
A pipeline mega-ADR
Closed deterministic applicability
Free-form not applicable claims
Single-writer lanes, one convergence point
Agents editing a shared file concurrently
Exact live SHA and route evidence
“Deploy succeeded” without proof
Truthful bounded CPU receipts
Automation claiming more than it applied
Error handling
Authority or doctrine conflict
Stop. Name both sources, identify the higher authority, preserve artifacts, and
route the conflict to the owning skill or repository decision process.
Applicability record invalid
Do not skip or execute the node. Report the rejected field, source artifact,
spec hash, and owning stage. Repair the source contract, then reevaluate.
Review or release gate fails
Do not declare completion. Fix within the same accepted envelope when safe;
otherwise rollback through the canonical path and record a new bounded wave.
Resume input is stale
Invalidate the affected node and all consumers. Reuse only checkpoints whose
input, output, and spec hashes still match.
