Build poc
Skill YasuakiOmokawa/skills/plugins/build-poc/skills/build-poc
Agent skills for improve AI driven development
npx -y skills add YasuakiOmokawa/skills --skill build-pocAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
やりたいこと (brief / PRD / gdocs URL) を技術調査して星取表を作り、最小実装でセルを裏どりして PoC を完成させるときに使用。「PoC を作って」「実現できるか検証して」「技術調査して星取表を作って」「案件を初期化して <gdocs URL>」「PRD の凍結スナップショットを取って」で起動。完了時に案件プランファイルへ /build-prototype 向けの申し送り節を追記する。
SKILL.md
5.3 KB, as published. Nobody here has run it
build-poc
やりたいことを PoC で裏どりする。引数がなくても会話から察して動く。自分で補えない値 (gdocs URL・実装対象リポジトリ等) だけ、まとめて 1 回で聞く。依頼が手順の一部だけを指す場合 (案件初期化のみ・凍結スナップショットのみ・星取表のみ等) は該当手順だけ実行し、残りが未了で あることを 1 行添える。
手順
- 案件プランファイルを用意する: 既定は
~/.claude/prototyping-projects/<案件名>/plan_<案件名>.md(ユーザー指定があればそちら)。既にあればそれを使う。冒頭にやりたいこと 1 段落・ 実装対象リポジトリ・PRD の所在を書く (gdocs 案件は手順 2 のテンプレートが冒頭を占めるので、 その配置指定に従う) - PRD の正本が gdocs なら凍結スナップショットを取る:
references/freeze_prd_snapshot.mdを Read して従う (タブ単体エクスポート wrapper と権限 deny 時の縮退手順を含む)。 以後の検証・設計はスナップショットだけを正とする。PRD が gdocs でなければこの手順は スキップと宣言する - 技術調査 → 星取表: 実現方式の候補を挙げ、評価軸 (実現可否・操作性・既存資産との 相性・工数・リスクなど案件に合わせて選ぶ — UI が無い案件では操作性を外す) との星取表 (候補 × 評価軸の表。セルは ◯/△/✕ + 根拠) をプランファイルに書く。この時点のセルは全て仮 — 根拠欄に (未検証) と明記する (調査は仮説の候補リストであり結論ではない。実案件で調査結果の 誤り 3 点を実装検証が訂正した)。 候補が実質 1 つで危険な前提の検証が主となる案件では、星取表の代わりに /iterate-with-prototypes の仮説 ledger (主張 / 検証方法 / kill 条件) を成果物にしてよい
- PoC クローズ基準を先に 1 行宣言する: 「勝ち筋候補のセルが実測根拠を持ったら PoC 終了」。 基準を超える作り込みはしない (基準の事前宣言が無いと PoC は「動く仕様の鏡」に変質する — 実案件で 87 コミット中 feasibility 検証は 20% のみだった)
- 最小実装で裏どり: 勝ち筋候補のセルを最小のコードで検証し、星取表の (未検証) を 実測根拠 (数値・スクショ・エラー) で置き換える。実測が取れたセルは候補を問わず記号も根拠も 実測に合わせて直し、取れなかったセル・測れなかった根拠は (未検証) のまま残す (棄却理由の裏付けになる)。検証したい条件が実入力に現れないときは合成 fixture を作って測る (これは最小実装の一部)。捨てる前提で書く。存命中の維持作業 (リファクタ・develop 追従マージ・ docs 整備) は検証に寄与しないので投資しない — 頼まれた場合も規律を示して /build-prototype 側へ 送り、送った内容は申し送りの「やらなかったこと」に残す (実案件で維持費が 87 コミット中 4 割を占めた)。実装対象リポジトリがある案件で PoC コードを PR に残す場合は /create-pr draft (タイトル先頭に [DONOTMERGE]、本文冒頭にも merge しない参照用と注記)。 スタンドアロン検証では PR を作らず、コードの所在だけ申し送りに書く
- 申し送りを書く: プランファイル末尾に
## 申し送り (PoC → プロトタイプ)節を追記する (見出し文字列は変えない — /build-prototype が同じ文字列で探す。本文は自由形式。 他の節が後ろに残っていたら前へ移し、この節をファイル末尾にする)。 内容 — 採用方式と根拠 (星取表の結論) / 裏どりで確定した事実と棄却した候補 / 触って得た操作性の知見と棄却した配置・導線 (PRD にも Figma にも載らない知見のため、 ここに記録しないと後工程のデザイン反映やリファクタで静かに消える。UI が無い案件は省略) / やらなかったこと / PoC コードの所在 (ブランチ・PR) / 実装対象リポジトリ
Gotchas
- 星取表と申し送りを 1 パスで書き上げると未実測値が実測根拠として残る — 仮 (未検証) 版を保存してから裏どり実装に着手する
併用推奨 skill
- /iterate-with-prototypes — 検証したい仮説が多い大きめ PoC の規律 (仮説 ledger と spike)
- /extract-figma-spec — Figma 再現が検証対象に含まれる場合
- /qa-ui — PoC UI の確認
- /build-prototype — 次工程 (この skill の申し送り節を入力にする)