---
name: build-prototype
description: PoC と案件プランファイルの申し送り節を受け取り、既存コードベースの慣習に合わせて DD (Design Doc) を起こせる水準のプロトタイプを実装するときに使用。「プロトタイプにして」「PoC を本実装の形に書き直して」「慣習に合わせて実装して」で起動。完了時にプランファイルへ /create-design-doc 向けの申し送り節を追記する。
---

# build-prototype

PoC を、既存コードベースの慣習に合った「DD を起こせる水準」のコードにする。
入力は案件プランファイルの申し送り節と PoC コード。見つからなければ会話と成果物から
察し、自分で補えない値だけまとめて 1 回で聞く。

## 手順

1. プランファイルの `## 申し送り (PoC → プロトタイプ)` を読む (節が無ければ PoC の
   成果物と会話から同じ項目 — 採用方式・確定事実・やらなかったこと・実装対象リポジトリ —
   を自分で整理してから始める)
2. PRD の正本が gdocs で、PoC 開始から PRD が動いた可能性があるなら、/build-poc の
   凍結スナップショット手順でこの時点の版を取り直す (本実装設計はこの版が凍結基準になる)
3. 実装対象リポジトリの慣習を調査する: 類似機能の配置・命名・レイヤ構造・テストの
   書き方を実ファイルで確認し、従う対象を宣言する
4. 申し送りの「確定した事実 / 棄却した候補 / やらなかったこと」を設計に反映する
   (棄却候補を再発明しない。やらなかったことは設計に含めるか後続に送るかを明記する)
5. 開発基準ブランチから新ブランチを切り、PoC の知見を使って慣習準拠で実装し直す
   (PoC コードのコピーではなく書き直し)。設計の分岐点が出たら /review-design を使う
6. テスト・lint を通し、/create-pr draft で PR を作る (プロトタイプは設計確定用 —
   ready for review にしない)
7. プランファイル末尾に `## 申し送り (プロトタイプ → DD)` 節を追記する
   (見出し文字列は変えない — /create-design-doc が同じ文字列で探す。本文は自由形式)。内容 —
   プロトタイプ PR・ブランチ / 従った既存慣習と配置 / 設計判断と根拠 (採らなかった案も) /
   PoC から変えた点 / スコープ外にしたこと

## 併用推奨 skill

- /review-design — 配置・パターン選定の事前レビュー
- /review-code-quality, /polish-before-commit — コミット前の品質パス
- /build-poc — 前工程 / /create-design-doc — 次工程 (この skill の申し送り節を入力にする)