Gm Brilliant Implementation

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:

1. Two or more player-facing or simulation systems change in one coordinated release.
2. Delegated or automatic CPU authority changes across resources, promises, policies, deadlines, or attention.
3. The work is explicitly multi-wave.
4. 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:

1. The target repository's complete governing instructions.
2. Its project-local GM implementation skill, when present.
3. Its project-local GM UI skill before UI, copy, or mobile decisions.
4. The available account or target-local project-context skill for repository and release context.
5. workflow-dag.md and pipeline-spec.json.
6. The phase-local reference named below only when that phase begins.

If a local authority conflicts with this orchestration layer, stop and name the authoritative source. Never copy or silently override the domain rule.

Reference Loading Table

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 call the learning skill. Call the Skill tool with 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

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.

References

• Pipeline specification
• Workflow DAG
• Stage contracts
• CPU Systems Harmony
• Quality gates
• Anti-rationalization core
• skills/game/game-design/SKILL.md
• skills/process/feature-lifecycle/SKILL.md
• skills/workflow/SKILL.md
• agents/project-coordinator-engineer.md