build-prototypelisted

# build-prototype PoC を、既存コードベースの慣習に合った「DD を起こせる水準」のコードにする。 入力は案件プランファイルの申し送り節と PoC コード。自分で補えない値だけまとめて 1 回で聞く。 ## 手順 1. プランファイルの `## 申し送り (PoC → プロトタイプ)` を読む。受け取る項目は 採用方式 / 確定した事実と棄却した候補 / 操作性の知見と棄却した配置・導線 / やらなかったこと / PoC コードの所在 / 実装対象リポジトリ。節が無ければ同じ項目を 自分で整理してから始める (探す場所は プランファイルの他の節 (星取表・検証メモ・ 保留欄) → PoC の成果物 → 会話)。整理結果は再構成と分かる見出しでプランファイルに 残す (固定見出し `## 申し送り (PoC → プロトタイプ)` は /build-poc の出力なので流用しない) 2. PRD の正本が gdocs なら、/build-poc の凍結スナップショット手順でこの時点の版を 取り直す (本実装設計はこの版が凍結基準になる)。取れないときは PoC 開始時の版を凍結基準 として続行し、リスクとして申し送りに残す (同手順の停止指示は案件開始時のもの — 取り直しでは止めない)。gdocs でなければこの手順はスキップと宣言する 3. 実装対象リポジトリの慣習を調査する: 類似機能の配置・命名・レイヤ構造・テストの 書き方を実ファイルで確認し、従う対象を宣言する (会話で述べ、手順 7 の申し送りにも残す) 4. 手順 1 の項目を設計に反映する (棄却された候補・配置・導線を再発明しない。操作性の 知見は PRD にも Figma にも残らないため、ここで落とすと復元できない。やらなかった ことは設計に含めるか後続に送るかを明記する) 5. 開発基準ブランチから新ブランチを切り、PoC の知見を使って慣習準拠で実装し直す (機構は書き直す。PoC で確定した振る舞いは保つ)。確定した振る舞いを固定するテストを repo のテスト慣習に合わせて追加する。設計の分岐点が出たら /review-design を使う 6. テスト・lint (repo が使っているもの。無ければ代替手段と理由を申し送りに 1 行残す) を 通し、変更をコミットしてから /create-pr draft で PR を作る (プロトタイプは設計確定用 — ready for review にしない)。PR が作れないときはブランチ名と commit hash が申し送りの参照先 7. プランファイル末尾に `## 申し送り (プロトタイプ → DD)` 節を追記する (見出し文字列は変えない — /create-design-doc が同じ文字列で探す。本文は自由形式)。内容 — プロトタイプ PR・ブランチ / 従った既存慣習と配置 / 設計判断と根拠 (採らなかった案も) / PoC から変えた点 / スコープ外にしたことと残ったリスク ## 併用推奨 skill - /review-design — 配置・パターン選定の事前レビュー - /review-code-quality, /polish-before-commit — コミット前の品質パス (起動は任意) - /build-poc — 前工程 / /create-d