Proto Loop

---
user-invocable: true
description: "プロトタイプの連作ループ。1案ごとに「確かめたい問い」を人間と決め、担当エージェントに設定集＋問いだけ渡して作らせ、Vibe確認の学びを設定集（Setting Book）へ蒸留して次のプロトに継ぐ。収束したら統合プロトを経てauto-buildへ引き継ぐ。auto-buildの前段（体験探索フェーズ）。旧 /auto-mvp の後継。"
---

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

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

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

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

## 成果物の置き場

| 成果物 | 置き場 | 性質 |
|---|---|---|
| 設定集（Setting Book） | `doc/draft/design/setting-book/`（ソースMD。`index.html` に統合してアーティファクト公開） | 発酵場所。**未合意**。ビジュアル付き |
| プロトタイプ | `proto/*` ブランチ または `samples/proto-N/`（本番ビルド・配布から除外） | 使い捨て |
| Figmaプロト | Figmaファイル（URLを設定集に記録） | 使い捨て〜SSOT種 |
| 昇格候補 | 設定集に「昇格候補」として印を付ける | **未合意**。人間が決めるまで上げない |
| 確定した判断 | `project-design-language` スキルへ昇格（**人間の合意後のみ**） | SSOT |

## 実行手順

### 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 へ還流する

## エージェント編成の目安

| 役割 | 担当 | 文脈 |
|---|---|---|
| 監督（このスキルの実行者） | メインセッション＋人間 | 全履歴を持つ。問い立て・蒸留・進行 |
| プロト制作者 | ラウンドごとに新しいサブエージェント | 設定集＋問いのみ（文脈遮断） |
| 批評 | `design-critic`（`/design-critique`） | 成果物の参照のみ。統合プロト前に1回 |

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

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