pol-probe

pol-probe skill の概要

pol-probe は何のためのものか

pol-probe skill は、Proof of Life probe を定義するための skill です。Proof of Life probe とは、本格的な実装に時間とコストを投じる前に、リスクのある仮説を検証するための使い捨ての検証用アーティファクトです。磨き込まれた MVP を作るのではなく、速くて反証可能な答えが必要なチームに向いています。

どんな人に向いているか

アイデアを実際に作る価値があるかどうかを見極めたいプロダクトマネージャー、創業者、デザイナー、エンジニアに向いています。特に pol-probe for Prototypes は、プロトタイプごっこに陥らず、見栄えより学びに集中したいときに有効です。

何が特長か

この skill は、スコープを絞ること、成功条件を厳しくすること、そして「使い捨てる」前提を強く促します。本当の価値は意思決定の質にあります。実現可能性の確認、タスク中心のテスト、ナラティブ型プロトタイプ、シミュレーション、vibe-coded な probe を切り分け、目的に合った実験を選べるようにしてくれます。

pol-probe skill の使い方

インストールして、見るべきファイルを確認する

まず skill manager から pol-probe install の流れで導入し、最初に skills/pol-probe/SKILL.md を開いてください。続けて、自分で probe を書く前に template.md と examples/sample.md も確認します。ここには補助スクリプトや参照フォルダはないため、価値の中心はコアの skill ファイル、テンプレート、そしてサンプルにあります。

あいまいなアイデアを使えるプロンプトにする

弱い入力は「この機能の検証を手伝って」という程度です。より良いプロンプトは「初回購入の SMB 顧客における checkout の摩擦を減らすための PoL probe を作成してください。リスクは、フォームが長すぎて離脱が起きることです。2日で実施できる低コストのテストで、合否基準と使い捨て方針を含めてください」という形になります。pol-probe usage は、仮説、リスク、対象ユーザー、失敗した場合に何が分かるのかを明示すると、ぐっと良くなります。

この skill に必要な情報

1つの仮説、主要なリスクを1つ、対象ユーザー、使える時間、そして十分に明確な答えを得られる中で最安のテスト方法を渡してください。これらが抜けると、skill は本来の probe 計画ではなく、一般的なプロトタイプの助言に流れやすくなります。最良の結果を得るには、期限、使えるツール、テスト後に下す意思決定などの制約も含めてください。

実務的な進め方

まず仮説を置き、次に probe の種類を選び、それから「期待を裏づける」のではなく「間違いを証明できる」成功条件を定義します。最後にタイムラインと使い捨て方針をまとめます。この順序が重要なのは、pol-probe guide の出力は、広い企画書ではなく、明確な実験設計を強制してこそ役に立つからです。

pol-probe skill の FAQ

pol-probe はプロトタイプ向け？ それとも MVP 向け？

これは検証用 probe のためのもので、MVP 向けではありません。持続的に使えるものをリリースしたいなら、この tool は不向きです。リスクのある前提が本当かどうかを学びたいなら、pol-probe for Prototypes は一時利用を前提にしているため、非常に相性が良いです。

普通のプロンプトと何が違うのか？

普通のプロンプトは、アイデアや下書きのアーティファクトを生成するだけかもしれません。pol-probe skill はより意図がはっきりしていて、反証可能な仮説、具体的なリスク、使い捨て方針を求めます。この構造があることで、単なるコンセプトではなく意思決定が必要な場面で、出力が実行しやすくなります。

初心者でも使えるか？

はい、何を証明したいのか、あるいは反証したいのかを言語化できるなら使えます。初心者がつまずきやすいのは、目的が広すぎるときです。1つの前提と1つのテストを定義できれば、この skill が現実的な probe に落とし込むのを助けてくれます。

使わないほうがいいのはいつか？

すでに解決策が分かっているとき、本番レベルのアーキテクチャが必要なとき、あるいは学習ではなくステークホルダー向けの説明が目的のときは使わないでください。成功・失敗のシグナルが曖昧な探索作業にも向きません。

pol-probe skill を改善するには

入力をもっと鋭くする

最大の改善ポイントは、仮説を測定可能にすることです。「ユーザーは気に入るはず」ではなく、「初回ユーザーは2分以内にフローを完了でき、エラーは2回未満」といった形にしてください。強い入力ほど、pol-probe usage の出力は検証しやすくなり、一般論も減ります。

早い段階で適切な probe の種類を選ぶ

リスクが技術面なら、実現可能性の確認を使います。リスクが理解度なら、タスク中心のテストが適しています。ステークホルダーの合意が必要なら、ナラティブ型プロトタイプのほうがよい場合があります。間違った種類を選ぶことは、pol-probe の主な失敗パターンの1つです。なぜなら、必要な証拠ではなく、別の証拠を集めてしまうからです。

確認ではなく失敗を前提に書く

この skill は、どんな結果なら中止するのか、方向転換するのか、スコープを絞るのかを明確にすると最も力を発揮します。明示的な失敗条件、小さなサンプルサイズ、そして破棄ルールを含めてください。そうすると pol-probe guide の有用性が上がり、楽観を意思決定の枠組みに変えられます。

1回目の実行後に改善する

最初の probe のあとで、希望ではなく実際に学んだことに基づいて仮説を見直してください。結果が曖昧なら、対象ユーザーを絞るかテストのスコープを小さくします。結果が否定的なら、そこから得た教訓を記録し、probe を MVP に磨き上げるのではなく削除してください。