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.

1. Delegated or automatic CPU authority changes across resources, promises,

policies, deadlines, or attention.

1. The work is explicitly multi-wave.
2. 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.

1. [workflow-dag.md](references/workflow-dag.md) and

[pipeline-spec.json](references/pipeline-spec.json).

1. 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 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](references/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](references/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](references/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.

References

• [Pipeline specification](references/pipeline-spec.json)
• [Workflow DAG](references/workflow-dag.md)
• [Stage contracts](references/stage-contracts.md)
• [CPU Systems Harmony](references/cpu-systems-harmony.md)
• [Quality gates](references/quality-gates.md)
• [Anti-rationalization core](../../shared-patterns/anti-rationalization-core.md)
• skills/game/game-design/SKILL.md
• skills/process/feature-lifecycle/SKILL.md
• skills/workflow/SKILL.md
• agents/project-coordinator-engineer.md