Dream Loop

コンセプトアートに近づける反復で、見事な 3D シーンを作ります。

skill の情報

参考: SKILL.md 全文

Dream Loop skill

とびきり見栄えのするビジュアル、特に 3D シーン（ゲームやアプリ。多くはブラウザの three.js/WebGL）を作るための自律的な工程です。理想の完成形をフォトリアルな コンセプトアートとして生成し、それを実装し、動いているビルドのスクリーンショットを撮り、 審査役にスクリーンショットとコンセプトを段階制の採点表で比べて採点させ、 収束するまで繰り返します。目標は、対象プラットフォームで許容できるフレームレート （例: ブラウザで 60 fps、最新のモバイルで 120 fps）を保ちながら、見た目で最も圧倒する結果です。

この skill は、Web アプリの一般的な機能、2D の UI デザイン、 見た目以外の品質は扱いません。扱うのは見た目の忠実度を上げるループだけです。

こんなときに使います

• ユーザーが「dream loop」と言ったとき、またはゲーム、シーン、アプリを非常に高い

グラフィックの忠実度で作ってほしいと頼んだとき。

• 既存のビジュアル作品に対して、仕上げを重ねるとき（下の「続きのループ」を

参照）。

事前に必要なもの

• コンセプトアート: image_generate ツール。使えない場合は止まって、

ユーザーにコンセプト画像（または接続できる画像生成 API）を頼みます。

• スクリーンショット: browser_exec。ビルドをローカルで配信し

（静的なビルドなら python3 -m http.server）、new_tab(url)、 wait_for_load()、capture_screenshot() の順に呼びます。

• 審査: vision_analyze（1回の呼び出しに画像1枚という制約の回避策は、審査の節を

参照）。

• 任意: アセットのモデリングに Blender。blender-3d-automation

skill を参照してください。アセット作業の並列化や、まっさらなコンテキストでの審査には delegate_task。

ループ全体に必要なツールがそろっていない場合は、早い段階でユーザーにそう伝えて 止まります。

早見表

手順

1. 目標のコンセプト

ユーザーがゲーム、シーン、アプリの説明をくれたら、そのまま進みます。コンセプトアートを 生成できないほど曖昧でない限り、確認の質問はしません。説明が なければ、説明を求めます。

作業用のコンテキストやファイルは .dream-loop/ に置き、gitignore に入れます（別の指示が ない限り）。

2. コンセプトアート

コンセプトは、写実的で質が高く、人を驚かせる目標です。いまの AAA タイトルが リアルタイムで動いているときの見た目を狙います。物理的にありえる質感（濡れた 石、ヘアライン加工の金属、布、ガラス）に本物らしい粗さと法線の細部があり、 正しいプロポーション、空気感（霧、もや、雨、ほこり、ボリュームライト）、 はっきりしたキーライトと深い影を持つ映画的なライティングがあること。 様式化したものや芸術的な解釈であってはいけません。理想の結果の本物の スクリーンショットに見えるべきです。

image_generate で生成するときは、次の失敗パターンを避けます。

• 作り込みすぎ: 写真のような散らかり、フィルムグレイン、何百もの細かい小物、

どの面にもあるノイズにしか見えない過剰な細部。モデリングしたアセットを使う リアルタイムのビルドではこれに追いつけませんし、そもそも見栄えもよくありません。

• 単純化しすぎ: アニメやおもちゃのような見た目、フラットな陰影、ぼてっとした

基本図形、何もない面。退屈で、ユーザーを感心させられません。

その中間を狙います。シェーダーでよく描ける美しい面と質感、 強い空気感とライティング、面白い配色、そして目を引く細かな作り込みを持つ 主役の要素に絞ること（すべての要素が注目を奪い合うのではなく）。

プロンプトでは「コンセプトアート」よりも「ゲーム内のスクリーンショット」を求め、ざらついた ノイズっぽい見た目を避けるよう指示します。できた画像は vision_analyze で確認し、 失敗パターンに当てはまったら、編集モードで image_generate に戻して 直してもらいます。.dream-loop/concept.png として保存します。

アートを自分で生成した場合（ユーザーが渡したものでない場合）は、ビルドのループに 入る前にいったん止まり、ユーザーの思い描くものと合っているか確認します。

3. 時間の予算

ユーザーが時間の予算を示したら、開始時刻を記録し、ラウンドの合間に 時計を確認します。予算に合わせるために見た目の忠実度を落としてはいけません。 最高の結果を目指し、急いだ作業を審査に出さないこと。作業を並列化・分散して （例: 独立したアセットには delegate_task）時間の目標に合わせますが、 手抜きはしません。全体としては出来上がっていても醜いものより、 意味のある美しい進歩を持って時間切れを迎えるほうがよいのです。

時間の予算がなければ終了基準に達するまで回しますが、トークンを大量に 使うかもしれないと最初に伝えておきます。

4. 実装のループ

コンセプトアートを見て一度に実装し、その最初の実装で採点表のすべての段階 （構図、テクスチャ、ライティング、細部）に効くようにします。アセットは丁寧に スカルプトしてモデリングします（許可されていれば外部のものを使います）。 アートスタイルがそれを求めない限り、単純な手続き型の要素や平らな面で妥協しません。 途中のファイルや計画は .dream-loop/ に書きます。

• Blender が入っていて、コンセプトに 3D アセットが含まれるなら、Blender での

モデリングを優先します（blender-3d-automation skill を参照）。複雑なアセットは delegate_task でサブエージェントに任せます。

• ユーザーが外部アセットを許可している場合は、単純なアセットでない限り、モデリングより

外部アセットを優先します。指定がなければ、Web からの外部アセットは使わない前提にします。

• 環境の重要な細部（景色、床、建物）で手を抜かないこと。単純な形は

ブロック状で、テカテカして、平らで、作り物に見えます。細かな作り込みと テクスチャが効くので、個別のスカルプトが必要です。

• テクスチャ、法線マップ、スカイボックスなどには image_generate を使います。

手続き型で作るより見栄えがよく、速く作れます。

5. スクリーンショット

ビルドを配信し（例: ビルドのディレクトリで python3 -m http.server）、 browser_exec で new_tab('http://localhost:8000')、wait_for_load() を呼び、 シーンが落ち着くのを待ってから capture_screenshot() を呼びます。比較が公平になるよう、 コンセプトアートと同じ解像度とアスペクト比にします。 .dream-loop/round-N.png として保存します。

6. 審査前の自己点検

毎回、提出する前に候補のスクリーンショットを自分で見直します。 中途半端なものを提出しないこと。スクリーンショットとコンセプトを並べて比べ、 審査に出せる状態かを正直に評価してログに残します。スコアが大きく上がると 確信できるときだけ提出します。厳しく、1ピクセルずつ点検します。大きなこと （物の欠落や誤り、縮尺、遠近、位置の間違い）も、小さなこと （描画の不具合、テクスチャのない平らな面、見苦しいライティング、足りない コントラスト、色あせや彩度の上げすぎ、ちらつく点、見苦しい影）も見ます。 面ごと、物ごとに見ていき、見つけたことを書き出します。

7. 審査

審査は、できればラウンドごとにまっさらなコンテキストを持つ新しいサブエージェント （delegate_task）に任せます。そのほうが客観的で安く済みます。審査役には、 最新のスクリーンショット、コンセプト、そして（ラウンド2以降は）前のラウンドの スクリーンショットと判定を渡します。

仕組み: vision_analyze は1回の呼び出しで画像を1枚しか受け取りません。審査役に 順番に呼ばせる（コンセプト、次にスクリーンショット、そのあと自分が書いた説明の 記憶をもとに比べる）か、もっとよい方法として、ImageMagick （convert concept.png shot.png +append compare.png）か PIL でラベル付きの左右並べの合成画像を作り、 その1枚を分析させます。

審査役へのプロンプト:

> あなたは、リアルタイムレンダリングをそのコンセプトアートと照らしてレビューする > アートディレクターです。スクリーンショットをコンセプトと比べ、次の採点表で > 0〜10 点をつけてください。採点表は段階制です。下の段階の要件がすべて満たされるまで、 > その上の段階の上限を超える点はつけられません。段階の関門には > 厳しくしてください。 > > - 段階1、形（0〜3）: カメラ、フレーミング、構図、主な物それぞれの位置と > おおよその大きさがコンセプトと合っていること。仕上げではなく配置を見ます。 > 主な要素がすべてあり、フレーム内の正しい区域にあり（フレームの幅・高さの > ~10% 以内）、おおよそ正しい大きさである（~25% 以内）こと。場所が正しく > 輪郭がなんとなく合っていれば、縁や表面が違っていても合格です。精度の細かい指摘は > 段階4まで取っておきます。これが満たされるまで上限は3。 > - 段階2、光と色（3〜5）: キーライトの向きと色、全体の > 露出（黒つぶれや白飛びがない）、影の深さ、配色、 > コントラスト、空気感。反射や発光なども見ます。シーンがコンセプトと比べて > 明るすぎたり暗すぎたりしないこと。細部（段階4）ではなく、フレーム全体で > 判断します。ライティング、反射、色、コントラストがおおむね正しくなるまで > 上限は5。 > - 段階3、質感と表面（5〜7）: どの面もひと目で > 正しい素材に見えること。テクスチャ、粗さ、透け感、濡れ、 > 反射。アセットが手続き的、ブロック状、つるつるのプラスチックに見えてはいけません。 > フレームの大部分を占める要素は、きちんとスカルプトされ作り込まれていること。 > これが満たされるまで上限は7。 > - 段階4、細部（7〜9）: 小さなこと。容赦なく細かく指摘し、 > 小さな物をひとつずつ近くで点検します。配置がほぼ完璧に揃い、 > 質感が非常に説得力のあること。正しくなるまで上限は9。 > - 段階5、見分けがつかない（9〜10）: 並べても、拡大しても > 通用すること。1ピクセルずつ細かく指摘します。 > > 前回の判定とスクリーンショットが渡された場合: あなたは最初の審査役ではなく、 > 続いていく審査役の1人です。一貫性を保ってください。まず、前回の各指示を > 新しいスクリーンショットに照らして LANDED、PARTIAL、NOT DONE のいずれかで判定し、 > PARTIAL と NOT DONE は引き継ぎます。結果が明らかに悪くなっていない限り、 > 前回の指示を覆さないでください。覆す場合は、そう明言し理由を述べます。 > > 出力形式: > 1. 1行目にスコア、2行目に「Tier N」（完全に通過した最も高い関門）。 > 1b. 前回の判定が渡された場合: LANDED / PARTIAL / NOT DONE の一覧。 > 2. 「Blocking:」*次の*段階の関門で失敗している具体的な点。実装する側は、 > ほかの何かが評価される前にこれを解消しなければなりません。要素と > 変更内容を、量も添えて名指しします。「岩: 積み重なった卵形の岩を、 > ひと続きの割れた岩盤1枚に置き換える。ひびは幅 2〜5cm で内部は暗く、 > 平らでプラスチックっぽく見えないよう表面にテクスチャを加える」のように書き、 > 「岩が作り物っぽい」とは書きません。 > 3. そのあとに、より上の段階からの指示を最大4つ、同じ書き方で、 > 取り戻せる点数が大きい順に並べます。 > > 行動につながらない感想（「作り物っぽく見える」）は書かず、具体的な原因を > 名指ししてください。どの指示も、このラウンドで実行できるものにします。切り上げないでください。 > 関門を完全に通過していなければ、上限はそのままです。

8. 終了基準

• スコアが 8 以上で、目標の FPS も許容範囲: 完了です。最新の

スクリーンショットをユーザーに見せ、さらに反復したいか尋ねます。

• スコアは 8 以上だが FPS が許容範囲外: 最適化します。まず見た目を損なわない改善、

次に見た目への影響が最小の改善。そのあと再審査して、後退していないことを確かめます。

• 行き詰まりが近い（最高スコアが2ラウンド続けて丸1点上がっていない、

または審査役が同じ差を3回指摘した）: 小さな調整をやめます。一歩 引いて、*やり方*のどこがスコアを頭打ちにしているのかを問います。1ラウンドで 構造的な大きな変更を1つ行います。アセットの作り方を変える（Blender でスカルプトする、 許可されていれば本物のモデル、テクスチャ、HDRI を取り込む）、ライティングのモデルを書き直す、 構図を作り直す、カメラを変える、などです。大きな変更は物を壊すので、自己点検は 丁寧に。パラメーターの調整を繰り返すのは、今回はなぜうまくいくのかを説明できるときだけです。

• 行き詰まった（すでに構造的な大きな変更を試し、スコアが3ラウンド横ばい、

審査役が細かい指摘ばかりか、GPU のないマシンでのレイトレーシングのような 無理なことを求めている）: 止まって、なぜ進めないのかをユーザーに伝え、選択肢を示します。

• それ以外: このラウンドで、最上位の1つだけでなく、効果の大きい差のすべてかほとんどに

対応します。ラウンドはコストが高いからです。数字を最も動かす差 （ライティング、テクスチャ、メッシュの細部）を優先します。元に戻すのは、スコアが 丸1点以上下がったときだけです。小さな下落は審査のブレで、ラウンド全体を戻すと 悪い変更と一緒によい変更まで捨ててしまいます。ある変更が明らかに悪化させていたら、 その変更だけを戻します。そしてループします。

続きのループ

既存の作品の上に作り込む場合（またはユーザーが仕上げのために skill を再度呼んだ場合）は、 何もないところから新しいコンセプトアートを作らないこと。いまあるものと 食い違うおそれがあります。代わりに、現在の作品のライブのスクリーンショットを撮り、 image_generate にそれの最高の版を描かせます（現在の スクリーンショット → 同じ構図の AAA グラフィック版）。それを 目標にします。求められれば、複数の画面で審査のループを並列に回せますが、その分 トークンのコストが上がります。

つまずきやすいところ

• 作り込みすぎ、または単純化しすぎのコンセプトアート（失敗パターンを参照）。それに

向けて実装を始める前に、コンセプトを直します。

• 中途半端なスクリーンショットを審査に出すこと。自己点検の関門には

理由があります。

• コンセプトと違う解像度やアスペクト比でスクリーンショットを撮ること。比較が公平でなくなり、

判定がぶれます。

• 審査役に方向がずれていると言われているのに、小さな調整ばかりに視野を狭めること。
• 1回の vision_analyze 呼び出しで両方の画像を審査すること。画像は1枚しか受け取らないので、

先に合成します。

• シーンの読み込みや落ち着きを待たずにスクリーンショットを撮ること。アセットの逐次読み込みや

アニメーションの立ち上がりのために、wait_for_load() のあとに待ち時間を入れます。

確認

• .dream-loop/concept.png があり、失敗パターンの見直しを通過している（生成した場合は

ユーザーの確認も済んでいる）。

• 各ラウンドに、スクリーンショット、ログに残した自己評価、そしてスコア + 段階 + 指示を

含む審査の判定がある。

• 終了は明示的な終了基準によってのみ行い、最終のスクリーンショットを、最終スコアと FPS の計測値と

あわせてユーザーに見せている。

dream-loop を元にしています。作者は Anshu Chimala（MIT）。上流のライセンスは LICENSE.txt として取り込んでいます。