/gm-brilliant-implementation

name: gm-brilliant-implementation
version: 1.1.1
description: "Run the full evidence-to-live implementation workflow for large, multi-system, multi-wave, or CPU-delegated 5 Star Booker GM programs."
agent: project-coordinator-engineer
user-invocable: true
allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Task, Skill]
routing:
  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:

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](references/workflow-dag.md) and [pipeline-spec.json](references/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

| Signal | Load | Why | | --- | --- | --- | | Start or resume any run | `references/workflow-dag.md`, `references/pipeline-spec.json` | 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](references/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 a