メニュー
Run the full evidence-to-live implementation workflow for large, multi-system, multi-wave, or CPU-delegated 5 Star Booker GM programs.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/notque/vexjoy-agent --skill gm-brilliant-implementationコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Classify user requests and route to the correct agent + skill. Primary entry point for all delegated work.
Structured multi-phase workflows: review, debug, refactor (tidy, clean up, untangle messy code without behaviour change), deploy, create, research.
Three.js app builder: imperative, React Three Fiber, and WebGPU in 4 phases.
SKILL.md を表示中
| 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"} |
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.
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.
Use this workflow only when the request is GM work and at least one condition is true:
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.
Before a run, read:
If a local authority conflicts with this orchestration layer, stop and name the authoritative source. Never copy or silently override the domain rule.
| 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 |
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.
Run these stages in dependency order:
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.
Run or reuse current evidence for:
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.
Run:
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.
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.
Run:
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.
Run:
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.
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.
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.
| 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 |
Stop. Name both sources, identify the higher authority, preserve artifacts, and route the conflict to the owning skill or repository decision process.
Do not skip or execute the node. Report the rejected field, source artifact, spec hash, and owning stage. Repair the source contract, then reevaluate.
Do not declare completion. Fix within the same accepted envelope when safe; otherwise rollback through the canonical path and record a new bounded wave.
Invalidate the affected node and all consumers. Reuse only checkpoints whose input, output, and spec hashes still match.
skills/game/game-design/SKILL.mdskills/process/feature-lifecycle/SKILL.mdskills/workflow/SKILL.mdagents/project-coordinator-engineer.md