# Build Poc

> Use when a technical choice or feasibility must be decided through a PoC or minimal experiment against success criteria in an executable environment.

- Skill: `yasuakiomokawa/build-poc` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yasuakiomokawa/build-poc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yasuakiomokawa/build-poc/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: YasuakiOmokawa (https://skillmd.com/u/yasuakiomokawa)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yasuakiomokawa/build-poc

---


# Workflow

1. 依頼から、答えるべき技術選定または実現可能性の問い、候補、評価軸、必須条件、選好条件、成功基準、制約、実行環境、許可された作成範囲、結果の出力先ディレクトリを特定する。候補が一つでも一候補として扱い、明示されたローカルの検証用データは利用可能な実行環境の一部として扱う。出力先ディレクトリが未指定なら推測で決めず指定を求める。問いを表すkebab-caseの案件slugを決め、出力先直下の `<案件slug>/` を案件ディレクトリとする。同名の案件ディレクトリが既に存在するなら書き込まず、別名または追記の指示を求める。
2. 候補を行、評価軸を列とする星取表を実験前に作る。各セルは `○`（観測した合格）、`△`（条件付き合格）、`×`（観測した不合格）、`未検証` のいずれかとし、`△` には条件と影響、観測済みセルには根拠を添える。調査、推定、予想だけのセルは `○`、`△`、`×` にせず `未検証` とする。`○`、`△`、`×` は合否の閾値を持つ列にだけ使い、閾値のない選好条件の列は相対順位と実測値で埋める。解釈により記号、順位、または結論が変わる多義的な条件は解釈ごとに列を分けて観測し、依頼文言に忠実な解釈を必須の列として扱い、確定を判断主体に求める。数値条件の測定単位、除外する費用、percentileの算出法は実験前に星取表の脚注として固定する。候補間の照合で決まる条件は両行に同一の観測結果を記入し、関係条件である旨を注記する。出力先が確定している場合に限り、この時点で案件ディレクトリを作成して実験前の星取表から `poc.md` に書く。出力先が未確定の間は星取表と観測記録を回答本文に保持し、確定後に `poc.md` へ移す。
3. 計画や必要条件の説明で代替せず、許可されたインターフェースに対して、結論を左右するセルから最小の局所実験を実際に実行する。検証コードは、後段でdraft PRとして参照できるよう対象リポジトリのworktree内の許可された範囲に置き、対象リポジトリが存在しない依頼では検証コードの所在を記録して手順7のPR作成を縮退する。検証コードとは人が書いたファイルだけを指し、実行生成物は含めず、実験の実行前に、許可された作成範囲の内側に生成物の除外を設定する。実験は元のブランチのworktree上で行う。依頼に無い測定入力は、seed等で決定的に固定して星取表の脚注に記録し、その妥当性の確定を判断主体に求める事項として申し送る。各試行の同一性を判断できる条件と観測値を記録し、星取表を実測に合わせて更新する。結論を変えないセルまで埋めるために実験を広げず、状態変化の根拠がない同じ実験を繰り返さない。
4. PoCは、採用候補の全必須条件が観測済みの `○` または依頼上の判断主体が条件と影響を明示的に受け入れた `△` で、結論を覆し得る `未検証` がない場合、または全候補が観測済みの必須条件で棄却されno-goを判断できる場合に完了する。ここで結論を覆し得るセルとは、必須条件、または実行可能な候補間の選定に実際に使う選好条件である。該当セルが `未検証`、または `△` の条件が未承認なら完了とせず、不足する証拠、追加測定に必要な条件、または判断主体による決定を示す。複数候補が全必須条件を観測済みの `○` で満たし、選定に使う選好条件が依頼に無い場合も完了とせず、選定に必要な選好条件の決定を判断主体に求める。完了判定は記号の種類でなく、結論を覆し得るセルが観測済みかどうかで行う。多義的な条件は、全ての解釈で結論が変わらない場合に限り、確認の回答を待たずに完了できる。
5. 採用候補が承認され、残る問いが既存コードベースとの配置、責務、慣習、契約の適合性だけになった場合に限り、プロトタイプへ進めると判断する。実現可能性が未解決ならPoCを継続し、全候補が棄却されたら停止または新候補を求める。不可逆な外部変更や組織判断が先に必要なら実験で既成事実を作らず、設計先行の判断を求める。
6. 作成や変更を許可された局所対象に限定し、外部状態への書き込みは具体的な変更先と内容が承認されている場合だけ行う。実験操作を送信した事実、返却値が明示する結果、再取得で確認した実状態を区別し、失敗や結果未確認から成功を作らない。
7. 検証終了時点で、完了、no-go、中断のいずれでも検証コードを保全する。現在のブランチ名を記録し、案件slugを含む検証用ブランチ（例: `poc/<案件slug>`）を現在のブランチから作成し、検証コードのファイルだけをcommitする。無関係な変更はcommitに含めない。依頼が外部状態の変更を禁じる場合を除き、pushと元のブランチをbaseとするdraft PR作成をそれぞれ独立の操作として一度だけ試行し、成否を操作ごとに記録して、draft PRを作成できた場合はURLを記録する。成功を確認できなかった操作は状態変化の根拠なく繰り返さず、ローカルブランチ名と失敗内容を記録して続行する。読み取り専用の事前確認は試行に数えず、事前確認で操作先が存在しないと判明した操作は試行せず対象なしとして記録する。その後元のブランチへ切り替え、現在のブランチが記録した元のブランチと一致することを確認する。復帰後のworktreeに検証コードを残置する場合は、その事実と除去手順を記録する。
8. 手順2で作成した案件ディレクトリの `poc.md` を結果で完成させる。見出し `## 問い`、`## 星取表`、`## 結論`、`## PR`、`## 申し送り` を持たせ、測定条件、試行別の観測値、採用・条件付き・棄却またはno-goの結論、PoCの完了可否、制約、失敗、未検証事項を含める。`## PR` にはdraft PRのURL、または失敗時のローカルブランチ名と失敗内容を記録する。`## 申し送り` は、新しいセッションのプロトタイプ作業が `poc.md` だけで前提を再構成できる自己完結した内容とし、判断主体の決定を待つ事項（採用承認、選好条件の確定等）を承認待ち事項として明記する。書き込み後に再読取して保存内容を確認し、回答内の要約だけでは作成済みとしない。出力先が未確定のまま終了する場合は書き出せない事実を報告し、`poc.md` に入れる内容の全量を回答本文に保持して返す。
9. `poc.md` のパス、星取表、結論、PoCの完了可否、PRのURLまたは失敗、制約、未検証事項、次に担うべき責務を返す。プロトタイプへ進めると判断した場合、後続作業への入力が `poc.md` のパスであることを明記する。別skillを暗黙に起動しない。