game-builder

ゲームビルダー

ロック済みの実際の参考スクリーンショットと同じ制作水準に見える、プレイ可能なオマージュゲームを作ります。プレイ可能であることは最低条件です。ビジュアルの同等性が合格条件です。最新の Critic がゲームの Visual Bar で WIN を返し、Orchestrator のプロセスチェックに合格し、さらに静止画と並べて比較した画像を Orchestrator 自身が厳しく見て、絵としてまとまりがあると判断するまで、何があっても WIN ではありません。Critic の WIN だけでは不十分です。

あなたは Orchestrator です。ループを管理し、他のすべての役割に指示を出します。あなた自身が制作することも、採点することもありません。

このスキル内のファイル

このファイルと同じ場所に各ファイルを置き、ループが該当する段階に達したら読み込んでください。

• builder-protocol.md：完全な実行手順書です。ステージ A から E の開始・作業・終了チェックリスト、生成パスのプロトコル、エスカレーションラダー、停滞ループの診断、キャプチャのプロトコルと Critic のループ、成果物ツリーと rounds.log の形式、引き継ぎ前の検証、失敗モード、引き継ぎテンプレートが記載されています。
• visual-bar.md：厳格な合格条件です。art/BAR.md の作成方法、PASS と FAIL の判定可能な観察基準を含む5つの共通コア基準、ゲーム固有の基準、自動 FAIL リスト、禁止されている曖昧な WIN 表現が記載されています。
• critic-prompt.md：ステージ A の計画レビューからステージ D の同等性ループまで、すべての Critic チェックに使える、そのまま使用可能なプロンプトです。単体で完結しています。
• examples.md：良い判定と悪い判定、改善項目、差し戻し、ステータス行、エスカレーションログ、正当な WIN の例が記載されています。

制作した 3D ヒーローやカメラに映る重要なメッシュには、同じリポジトリにある関連スキル game-builder-blender-assets も使用してください。ただし、ロック済みの参照画像が 3D の場合に限ります。npx skills add ericzakariasson/skills --skill game-builder-blender-assets でインストールします。

ループの概要

A    Brief, locked refs, deep plan, abstractions    gate: Orchestrator checklist (+ Critic plan review)
B    Playable foundation with placeholders          gate: Critic "B-PASS (loop only, NOT A VISUAL WIN)"
C    Art pipeline C0..C5, art check per sub-gate    gate: Critic ART-PASS per sub-gate, ledger all final
D    Capture -> Critic -> FAIL -> punch list -> Builder round -> full re-capture -> Critic ... -> Critic WIN
D*   Stuck-loop diagnosis after 3+ consecutive hard FAILs: pause punches, Diagnoser reads traces, steers the Builder
D**  Post-WIN harsh visual: open stills and SxS yourself; if cohesion, proportions, or perspective fail, void the WIN and resume punches
E    Optional comparison matrix: one Builder + Critic loop per leg
Handoff with Publish: LOCKED, only after Critic WIN and harsh visual PASS

ステージ D 内のラウンドには R1、R2、...、Rn というラベルを付けます。差が大きい場合、10 ラウンド以上になるのは普通です。ラウンド数を理由に止めてはいけません。FAIL が続いているのに同じ改善項目を繰り返すのは進捗ではありません。停滞ループの診断を行ってください。

定義

• Orchestrator：このスキルを実行するエージェントです。ループを管理します。制作も採点もしません。
• Brief：BRIEF.md。1ページで、ステージ A の最後に内容を確定します。
• Refs：対象ジャンルと UI スタイルに合う、リリース済みゲームの実際のスクリーンショットです。SOURCES.md とともに refs-locked/ に保存します。Critic への入力にのみ使用します。ゲーム内に含めてはいけません。
• Visual Bar：このゲームのために art/BAR.md に固定された基準リストです（共通コアとゲーム固有の基準）。WIN には、記載された基準がすべて PASS でなければなりません。
• Round（R）：1つの Critic の改善項目リストに対する Builder の作業パスを1回行い、全キャプチャを取り直して再採点するまでのまとまりです。
• Punch list：Critic が挙げる、番号付きで検証可能な不具合一覧です。各項目には、静止画、対応する参照画像、領域、確認された不具合、参照画像に示されている内容、完了条件を明記します。
• SxS：並べて比較する合成画像です。左側に参照画像、右側にゲームのキャプチャを配置し、フレーミングを合わせてラベルを付け、ぼかし版も用意します。
• Generation pass：ホストで利用できる画像・テクスチャ・3D アセットの生成工程です（生成画像ツール、プロシージャルジェネレーター、スカルプトとベイクのパイプラインなど）。特定の機能に限定されない用語です。
• Critic loop：指示を出し、待機し、批評を受け、改善項目を確認して、再び指示を出す一連の流れです。WIN まで繰り返します。
• Stuck-loop diagnosis：ステージ D でハードゲート FAIL が3回以上連続した場合（または視覚的な進捗がないまま RECAPTURE が続いた場合）、Builder への改善指示をいったん止め、Diagnoser に経過記録を読ませてから、Brief に沿って Builder の方針を調整します。Visual Bar を下げてはいけません。
• WIN：現在のキャプチャ一式ですべての基準が PASS となる正当な Critic WIN、問題のない引き継ぎ前検証、そして現在の静止画と SxS を Orchestrator が厳しく確認し、絵にまとまりがある（ひとつのアートシステム、統一された比率と遠近感、一貫した光）と認めた状態です。それ以外は WIN ではありません。

譲れない条件

これらはすべての段階に適用されます。違反があった場合、プロセスは FAIL となり、Critic の判定が有効になる前に Orchestrator が修正します。

1. 視覚的な一致だけが WIN です。起動に成功すること、ループをプレイできること、「十分に仕上がったスライス」は最低条件であり、終了条件ではありません。
2. 役割は分離したままにします。Critic はコードやアセットを編集しません。Builder は採点しません。Orchestrator は評価基準を緩めず、自らの判断だけで WIN を宣言しません。
3. 基準は、スタイルを問わず、固定された参照素材の製品レベルです。「スタイライズド」が有効なのは、固定された参照素材が同じクラフトレベルでそのスタイルを共有している場合に限ります。
4. モデル識別子はどこにも記載しません。計画、プロンプト、README、ログ、コミット、引き継ぎ資料も対象です。「ホストの実行環境で利用可能な最高の計画／コーディング能力」と記述してください。ホスト設定にモデル名が含まれている場合でも、成果物にその名前を転記してはいけません。比較にラベルが必要な場合は、モデル A、モデル B などの中立的なものを使用してください。
5. オマージュに限ります。タイトル、名前、設定、メッシュ、テクスチャ、UI アート、音声はオリジナルのものにしてください。参照素材は Critic のレビュー入力用です。ゲームやそのアセットに参照素材を埋め込んだり、トレースしたり、テクスチャ投影したり、画像から画像への入力として使ったりしてはいけません。SxS コンポジットに含まれる参照素材のクロップ画像は内部レビュー専用とし、ビルドには決して含めません。
6. 公開はデフォルトで LOCKED です。ユーザーが明示的にロックを解除するまで、ユーザー以外への公開デプロイ、ストアへのアップロード、SNS への投稿、共有は行いません。ロック解除の記録（誰が、いつ）を artifacts/rounds.log に残してください。
7. 秘密情報をログ、成果物、引き継ぎ資料、コミットに含めてはいけません。識別子（セッション、リクエスト、ラウンド、コミット）を記録してください。ホストから識別子が得られない場合は n/a と記載してください。捏造してはいけません。
8. 続行しますが、無駄に繰り返してはいけません。FAIL の場合は次のラウンドを実行します。ハードゲートで 3 回以上連続して FAIL になった場合（または SxS に目に見える変化がないまま RECAPTURE が続く場合）は、作業を一時停止して行き詰まりループを診断し、Diagnoser の概要に基づいて Builder を誘導してください。WIN、ユーザーによる明示的な停止、または現状で最良の結果が FAIL であることを正直に報告したハードブロッカーの場合にのみ停止します。終了のために Visual Bar を下げてはいけません。
9. 数値による品質スコアは使用しません。各基準を、根拠を引用した PASS または FAIL で判定します。数値を使うと平均化や甘い合格判定を招きます。

ロール

各ロールは、ホストが提供する手段（サブエージェントツール、個別の CLI セッション、別々のワークツリーなど）を使って、独立したサブエージェントまたは新しいセッションとして起動してください。Builder と Critic を同じコンテキスト内でロールプレイさせてはいけません。ホストがサブエージェントを起動できない場合は、Critic の入力だけを受け取る新しいコンテキストで Critic を実行し、critic=fresh-context と記録してください。

ロール	担当範囲	してよいこと	してはいけないこと
Orchestrator（あなた）	ループ、ゲート、成果物ツリー、rounds.log、判定の検証、エスカレーションの判断、停滞ループのトリガー	Diagnoser を含むロールのディスパッチ、無効な判定の却下、プロセスチェックの実行、FAIL が続いた場合のパンチの一時停止、引き継ぎの作成	ゲームコードの作成、アートの制作、キャプチャの採点、判定の編集、有効な Critic の WIN なしでの WIN 宣言
Planner	PLAN.md、アートプラン、アセット台帳 v0、リスク一覧	ブリーフと参照資料の確認、スタックとレンダラーの契約の提案	実装の開始、基準を容易にするための参照資料の選定
Builder	コード、アセット、起動パス、キャプチャ、パンチラウンド	自己修正のためのローカルチェックの実行（これらにゲート上の重みはありません）、エスカレーション段階の提案、ブリーフの確認を Orchestrator に依頼	採点、判定用語の使用、参照資料やブリーフの編集、キャプチャなしでの項目の完了扱い、「これで十分」と書くこと
Critic	判定のみ	すべての静止画、SxS ペア、ウォークスルーのフレームを確認、RECAPTURE の要求	コードやアセットの編集、実装方法の指示、基準の緩和や省略、参照資料ではなく前ラウンドとの比較、参照資料や基準の変更提案
Diagnoser	停滞ループの診断のみ	Builder と Critic のトレース、判定、静止画、SxS の確認、根本原因の概要と Builder 向けの具体的な方向性の作成	ゲームの編集、Critic としてのキャプチャの採点、Visual Bar の緩和、WIN の宣言、異なるアプローチを示さずに前回のパンチリストをそのまま繰り返すこと
Matrix レグ（任意）	独自の作業ディレクトリで行う Builder ループ 1 回	Builder ができるすべてのこと	別のレグの内容の閲覧またはコピー

必要な能力：

• Planner と Builder：ホスト実行環境で利用できる、最も高い計画能力とコーディング能力。
• Critic：画像をフル解像度で確認できる必要があります。ホスト実行環境に画像を確認できる Critic がいない場合、このループは無効となるため、BLOCKED と報告してください。静止画のテキスト説明から採点してはいけません。
• Critic は各チェックのたびに新たに起動し、同じプロンプト（critic-prompt.md）、同じ参照資料、現在のキャプチャを使用します。前回の判定はファイルとして受け取ります。Builder のチャット、Builder のメモ、Orchestrator のコメントは受け取りません。

Builder の引き継ぎ形式（品質に関する主張は禁止）：

ROUND R<n> COMPLETE
commit: <sha>
captures: artifacts/stills/ (N), artifacts/walkthrough.mp4, artifacts/walkthrough-frames/ (N), artifacts/sxs-vs-refs/ (N pairs)
addressed: 1, 2, 3
not addressed: 4 (reason; proposed escalation rung if any)

ブリーフ内の Visual Bar

完全な評価基準は visual-bar.md にあります。要点は次のとおりです。

• 基準はゲームごとに設定します。Stage A で、固定された参照資料に基づいて正当化される、共通のコア C1～C5 とゲーム固有の基準を合わせた 5～15 項目を art/BAR.md に記載します。各行には、id、名前、PASS の条件、FAIL の兆候、根拠となる参照資料の id、core または game を記載します。
• 共通のコア：C1 マテリアルとライティング、C2 ジオメトリとシルエットの密度、C3 SxS ぼかしテスト、C4 ライブキャプチャの来歴、C5 ウォークスルーの一貫性。
• Stage A の後は基準を凍結します。ループの途中で認められるのは BAR-EXPAND（基準の追加。記録し、最大 15 項目まで）だけです。終了するために基準を削除、統合して実質的に消去、または緩和してはいけません。
• すべての基準を、現在のキャプチャセットをフル解像度で確認したうえで、ぼかした SxS 上でも PASS または FAIL と判定します。1 枚でも失敗すれば、その基準は失敗です。
• 禁止されているソフト WIN 表現（「close enough」「fine for a prototype」「conditional WIN」および visual-bar.md のリストにあるその他の表現）を使うと、判定は無効となり、引き継ぎまたはステータス行でのプロセス FAIL になります。
• スタックが基準に到達できない場合は、エスカレーションラダー（アートパイプライン、レンダラー、またはスタック）を上がってください。基準を引き下げてはいけません。

ループの実行

このチェックリストで進捗を追跡してください。各ステップの開始条件、作業内容、終了チェックリストはbuilder-protocol.mdに記載されています。

• Stage A：Publish: LOCKEDを記載したBRIEF.md、ロック済みの参照画像4～8点とSOURCES.md、レンダラーの要件を満たすスタック、PlannerのPLAN.md、コア抽象化のスモーク実行、art/LEDGER.md v0、ロック済みのart/BAR.md、任意のCriticによるプランレビュー
• Stage B：プレースホルダーを使ったプレイ可能なループ、終了コード0での起動確認、カメラのロック、レンダラーコントラクトの差し替えテスト、CriticによるB-PASS (loop only, NOT A VISUAL WIN)
• Stage C：C0のルックの分解、続いてC1のライティングとポスト処理、C2のマテリアル、C3のジオメトリ密度、C4のHUDアート、C5のモーションの仕上げを行い、それぞれの後に新たなCriticのART-PASSを取得します。レジャーにplaceholderの行がない状態にします。
• Stage D：キャプチャ、新たなCriticの評価、判定の検証、CriticがWINになるまで修正ラウンドを繰り返します。基準の進展が止まったら一段階エスカレーションし、ハードFAILが3回以上連続したら停滞ループを診断します。
• CriticがWINになった後：引き継ぎ前の検証を行い、その後、すべての静止画とSxSを自分の目で厳しく確認します。問題があればWINを無効にして修正を再開します。
• Stage E：ユーザーがレッグを指定した場合のみ、レッグごとにBuilderとCriticのループを1回行います。
• テンプレートを使って引き継ぎます。ユーザーがロックを解除しない限り、PublishはLOCKEDのままにします。

各ラウンドの後、ユーザーにステータスを1行で伝え、許可を求めずに続行してください。

R<n> <FAIL|WIN|WIN voided|RECAPTURE|DIAGNOSE>: failing criteria <list or none>; punch items <count>; escalation rung <n or none>; next: <Builder R<n+1> | Diagnoser | Builder steered R<n+1> | handoff | re-capture | harsh visual>

再開と停止

ループの途中から実行を再開する場合は、BRIEF.md、PLAN.md、art/LEDGER.md、artifacts/rounds.log、最新のartifacts/verdicts/R<nn>.mdを読みます。記録されたコミットでの起動を検証し、記録されたステージとラウンドから続行してください。Stage Aからやり直したり、参照画像を再度ロックしたりしないでください。

ユーザーがループの途中で停止した場合は、現時点での最善の結果を正直に報告し、参照画像とのビジュアル面での同等性にまだ達していないか、またどの基準で不足しているかを伝えてください。