build-poclisted

# build-poc やりたいことを PoC で裏どりする。引数がなくても会話から察して動く。自分で補えない値 (gdocs URL・実装対象リポジトリ等) だけ、まとめて 1 回で聞く。依頼が手順の一部だけを指す場合 (案件初期化のみ・凍結スナップショットのみ・星取表のみ等) は該当手順だけ実行し、残りが未了で あることを 1 行添える。 ## 手順 1. **案件プランファイルを用意する**: 既定は `~/.claude/prototyping-projects/<案件名>/plan_<案件名>.md` (ユーザー指定があればそちら)。既にあればそれを使う。冒頭にやりたいこと 1 段落・ 実装対象リポジトリ・PRD の所在を書く (gdocs 案件は手順 2 のテンプレートが冒頭を占めるので、 その配置指定に従う) 2. **PRD の正本が gdocs なら凍結スナップショットを取る**: `references/freeze_prd_snapshot.md` を Read して従う (タブ単体エクスポート wrapper と権限 deny 時の縮退手順を含む)。 以後の検証・設計はスナップショットだけを正とする。PRD が gdocs でなければこの手順は スキップと宣言する 3. **技術調査 → 星取表**: 実現方式の候補を挙げ、評価軸 (実現可否・操作性・既存資産との 相性・工数・リスクなど案件に合わせて選ぶ — UI が無い案件では操作性を外す) との星取表 (候補 × 評価軸の表。セルは ◯/△/✕ + 根拠) をプランファイルに書く。この時点のセルは全て仮 — 根拠欄に (未検証) と明記する (調査は仮説の候補リストであり結論ではない。実案件で調査結果の 誤り 3 点を実装検証が訂正した)。 候補が実質 1 つで危険な前提の検証が主となる案件では、星取表の代わりに /iterate-with-prototypes の仮説 ledger (主張 / 検証方法 / kill 条件) を成果物にしてよい 4. **PoC クローズ基準を先に 1 行宣言する**: 「勝ち筋候補のセルが実測根拠を持ったら PoC 終了」。 基準を超える作り込みはしない (基準の事前宣言が無いと PoC は「動く仕様の鏡」に変質する — 実案件で 87 コミット中 feasibility 検証は 20% のみだった) 5. **最小実装で裏どり**: 勝ち筋候補のセルを最小のコードで検証し、星取表の (未検証) を 実測根拠 (数値・スクショ・エラー) で置き換える。実測が取れたセルは候補を問わず記号も根拠も 実測に合わせて直し、取れなかったセル・測れなかった根拠は (未検証) のまま残す (棄却理由の裏付けになる)。検証したい条件が実入力に現れないときは合成 fixture を作って測る (これは最小実装の一部)。捨てる前提で書く。存命中の維持作業 (リファクタ・develop 追従マージ・ docs 整備) は検証に寄与しないので投資しない — 頼まれた場合も規律を示して /build-prototype 側へ 送り、送った内容は申し送りの「やらなかったこと」に残す (実案件で維持費が 87 コミット中 4 割を占めた)。実装対象リポジトリがある案件で PoC コードを PR に残す場合は /create-