[ループ] プロト連作 /proto-loop

auto-build のフル工程は重く、着手時点では人間も答えを持っていない。その前段として、動くプロトタイプを1案ずつ連作し、触った学びを「設定集」に蒸留して次の案に継ぐ体験探索フェーズを担う。無指示の並列発散はしない — アイディアを練る過程そのものを工程にする。このスキルは統合プロトの選定までが範囲であり、本実装（TDD/レビュー収束/PR）は行わない。

AI動画制作の作法の移植: 先にキャラクター・世界観の設定資料を作り、出力を見て資料とプロンプトを磨き、そこから本番を作る。ソフトウェアでは「設定資料＝設定集」「出力＝プロトタイプ」「本番＝auto-build」に対応する。

入力: $ARGUMENTS

• プロンプト1文（作りたいものの種）または既存の設定集パス（続きから回す場合）

成果物の置き場

実行手順

0. 世界観の初期化（初回のみ）

• project-design-language を薄く書く（TBDだらけでよい。推測で埋めない）
• 外部デザイン知識ベース欄が記入されていれば（例: design-brain）、その優先順に従って読み込み、以後の全プロト制作の前提にする
• 設定集の骨組みを作る: 世界観・トーン / 採用した表現 / 不採用の表現 / 画面の型 / プロンプト集 の5セクション

1. 問いを立てる（人間と・毎ラウンド必須）

• 「このプロトで何を確かめたいか」を人間と1〜3行で確定する（体験仮説）
• 例:「初回訪問の第一印象は静かな方がいいのか、賑やかな方がいいのか」「この操作は直接操作かコマンドか」
• 問いなしでプロトを作り始めない（無指示発散の禁止）

2. 媒体を選ぶ

• proto-medium スキル（判断ガイド）を通して Figma / コード / 併用 を決め、理由を一言添えて人間に確認する
• 基準の要約: 止まっている絵で判断できるなら Figma、動かさないと分からないならコード

3. 制作（1プロト＝1エージェント）

• 担当サブエージェントを起こし、設定集＋今回の問い＋（あれば）外部知識ベース参照だけを渡して作らせる（会話履歴は渡さない。文脈遮断で新鮮な解釈を得る）
• 品質ゲートは最小限（動く＋スクリーンショット）。テストピラミッド・レビュー収束・PRは意図的に省略
• 比較軸が明確なラウンドに限り2案並行を許可（例: トーンA vs トーンB。担当エージェントは別々に）。軸のない3案並列はしない

4. Vibe確認（人間・必須）

• 人間が触って「いい / 違う」を出す。言語化しにくければ「どっちが近いか」で拾う
• ここは Human in the Loop。スキップ禁止

5. 設定集へ蒸留

• Vibeの結果を設定集に反映する:
  • 採用した表現: スクリーンショット＋なぜ良いか
  • 不採用の表現: なぜ違うか（負の例は平均への回帰を止める最強の制約）
  • プロンプト集: 次のプロトを作るための指示文を、今回の学びで書き直す
• 設定集の index.html を再生成してアーティファクト公開（同じURLを維持。開発者が眺めて「これいいね」と言える状態を保つ）
• 昇格候補を提示する（上げるかは決めない）: project-design-language に上げたい判断があれば、 設定集に「昇格候補」として印を付け、候補として人間に提示する。 ⚠️ AIは昇格の可否を判断しない。 迷ったかどうかに関わらず、上げるのは人間が決めてから （judgment-harness の「メモとSSOTを分ける」）
• 人間と次を決める: もう1ラウンド回すか、収束に向かうか／提示した昇格候補を上げるか

6. 統合プロト（収束）

• 各ラウンドの「採用」を束ねたいいとこ取りの1本を作る（新しい担当エージェント＋設定集で）
• 人間の最終Vibe確認。ここで出た「もう少し」は設定集に記録して統合プロトに反映

7. 本番へ引き継ぎ

• 要件へ上げるものを人間と決める（関所）:
  1. 設定集から「要件になりうるもの」を一覧にして提示する（プロトが完走したことと、要件になることは別）
  2. 上げると決まったものについて、rdd.md に書き込む文面そのものを見せる
  3. 合意を得てから書き込む。⚠️ 合意なしに doc/input/ へ書かない
• 選定結果と学びを doc/input/rdd.md へ反映（プロトのコードは仕様の種。再利用は最小限、本実装はTDDで作り直す）
• project-design-language の昇格漏れを最終確認（昇格は人間の合意後のみ）
• auto-build --from-proto <設定集パス> で本実装フェーズへ（設計→実装→テストの自律ループ）

8. 磨きラウンド（本番終盤・任意）

• auto-build 完了後の Vibe確認で出た「この機能をもう少しこうしたい」は、polishタスクとして起票し（experience-plan で状態×見た目×周辺を列挙）、auto-task で回す
• 磨きで得た判断も設定集→design-language へ還流する

エージェント編成の目安

やってはいけない

• 問いを立てずにプロトを作り始める（無指示の並列発散を含む）
• 発散フェーズでのTDD・レビュー収束・PR作成（後段の auto-build に任せる）
• 人間のVibe確認を経ずに次のラウンドへ進む・1案へ収束させる
• プロト資産をそのまま本番コードとして残す（samples/proto扱いを崩さない）
• 設定集を更新せずにラウンドを終える（学びが揮発する）
• ⚠️ ラウンドの途中で doc/input/（rdd.md 等のSSOT）へ直接書き込む。 書けるのは doc/draft/ だけ。要件へ上げるのはステップ7の関所を通ってから （実測: この迂回が起きると、設定集を経ずに設計判断が要件へ入る → ADR-026）
• ⚠️ 昇格の可否をAIが判断する。候補の提示までが担当で、上げるのは人間が決める

自己評価

• 成功自信度: (1-10)
• 一言理由: {回したラウンド数・設定集に蒸留できた判断の数を踏まえて記載}