first-customer-finder

最初の顧客を見つける

スタートアップの URL や製品の説明から、見込みのある最初の顧客を、根拠に基づく短いリストにまとめます。公開情報を活用し、プライバシーを尊重して、見込み顧客と購入が確認された顧客を区別します。

見込み顧客の調査やスコア付けを始める前に references/research-framework.md を、最終レポートを作成する前に references/report-artifact.md を読んでください。履歴の保存、フィードバック、検索のやり直しを行う場合は、references/feedback-and-history.md も読んでください。

既定では英語を使用し、明示的な言語指定があればそれに従ってください。チャットでの引き継ぎは簡潔にし、有用な詳細はレポートに記載してください。調査には利用可能なウェブ検索／ブラウザーのツールが必要です。同梱の Python ヘルパーでできるのは、ローカルファイルの検証、エクスポート、管理のみです。ライブブラウジングを利用できない場合は、見込み顧客を捏造せず、その制約を報告してください。

ワークフロー

1. 製品を理解する

• 提供された URL、リポジトリ、ランディングページのコピー、または製品の説明を確認します。
• 製品、得られる成果、購入者、ユーザー、価格または購入プロセス、地域、最も有力なユースケースを特定します。
• 主要な ICP を 1 つ、隣接する ICP を 1 つ定義し、課題の発生要因、肯定的なシグナル、除外条件を定めます。
• 安全に推測できる範囲で、不足している背景情報を補い、推測であることを明記します。曖昧さによって調査内容が大きく変わる場合に限り、簡潔な質問を 1 つします。
• 製品ごとに一貫したワークスペースフォルダーを 1 つ使用します。履歴が存在する場合は、検索前に保存された設定と除外対象の見込み顧客を確認します。近くにあるという理由だけで、別の製品の履歴を読み込んではいけません。履歴の保存先を簡潔に伝え、履歴を保存しないでほしいという要望には従います。

2. 公開シグナルに基づく検索計画を立てる

以下について、最新の公開情報を検索します。

• ツールや代替手段を明示的に求めているもの
• 対象の課題を一人称で説明しているもの
• 手作業のワークフローや、繰り返し発生する回避策への不満
• 移行、解約、競合への不満を示すシグナル
• 採用、新製品の公開、事業拡大、関連ワークフローの導入など、購入のタイミングにつながる公開企業の変化

関連性がある場合は、アクセス可能な公開 X の議論、GitHub の Issue、フォーラム、レビュー、企業ページなど、複数の検索の切り口と情報源の種類を活用します。検索エンジンは情報源を見つけるための手段であり、根拠そのものではありません。元のページを開き、公開日と確認日を別々に記録して、シグナルを実際の投稿者／企業に帰属させます。情報源がブロックされている場合や、検索結果の抜粋しか確認できない場合は、適格な候補リストから除外し、調査範囲の制約を説明します。すべてのプラットフォームを検索したかのように示してはいけません。

3. 安全に調査する

• 公開され、意図的に共有された職業上または業務上の情報のみを使用します。
• ログインの壁、ペイウォール、アクセス制御、レート制限、robots の制限を回避してはいけません。
• データブローカー、漏えいデータセット、非公開グループ、個人のメールアドレスの特定、電話番号の補足、機微な個人情報を使用してはいけません。
• 保護対象の特性を推測したり、健康、経済的困窮、政治的信条、性的指向、宗教、その他の機微な属性を使って個人をターゲットにしたりしてはいけません。
• 製品に関連する企業、公開された職業プロフィール、公開された依頼、コミュニティへの投稿を優先します。
• 引用は最小限にとどめ、原則として言い換えます。重要な課題やタイミングのシグナルにはすべてリンクを付けます。

4. 見込み顧客を評価し、重複を除外する

同梱のフレームワークを使って、各見込み顧客をスコアリングします。

• 課題の深刻度
• プロダクトとの適合性
• タイミング
• 公開情報からの連絡可能性
• 根拠の質

重複や適合度の低い候補は除外します。entity_url には、名前だけや共有プラットフォームのホームページではなく、確認済みの企業ホームページまたは公開されている職業プロフィールを使います。1つのエンティティに複数のシグナルがある場合もあります。引用できる課題、ニーズ、またはタイミングのシグナルがない見込み顧客は、推測上の適合候補にすぎないため、主要な候補リストに含めてはいけません。

その問題がすでに解決済みか、発信者が購入者ではなく販売者か、プロダクトに必要な機能がないか、購入者が指定されたプロフィールから外れていないかを確認します。重要な反証情報は注意事項に記載するか、候補から除外します。数値スコアが高くても、矛盾する証拠を覆すことはできません。弱い候補で指定数を埋めてはいけません。

見込み顧客が関心を持っている、同意している、または購入する予定であると決して断言してはいけません。出力には「公開情報のシグナルに基づく潜在顧客」と表示します。

5. アウトリーチの文面を作成する。送信はしない

• 対象となる役職／職能を特定し、観察済みか推定かを明記します。実在する意思決定者の名前をでっち上げてはいけません。
• 具体的で公式または公開されている連絡経路を確認します。該当する公開スレッド、公開されている業務連絡先ページ、または公開職業プロフィールが該当します。そのURLと、適切な経路である理由を記録します。経路が公開されていても、そこでプロモーションをしてよいという許可ではありません。関連するコミュニティのルールを確認してください。適切な経路が見つからない場合は、その旨を伝え、推測した宛先ではなく手動での調査手順を提示します。
• 購入者が使う課題の表現を用い、受諾、辞退、転送が可能な、具体的で負担の少ないCTAを含む短い書き出しを1つ作成します。ワークフローのレビュー、チェックリスト、デモなど、現実的な次のステップを提案します。アセット、インテグレーション、顧客成果、または機能の存在が確認できていない限り、すでに存在すると主張してはいけません。
• 相手を知っているふりをしたり、親しさを誇張したり、無関係な個人情報に言及したりしないでください。
• ユーザーが別途依頼し、その行為を許可しない限り、メッセージの送信、フォームの送信、接続、フォロー、コメント、CRM レコードの作成を行ってはいけません。

6. レポートを作成し、次回の検索に必要なコンテキストを保存する

最も実行に移しやすい証拠を先に提示します。次の順序を使います。

1. 判定 — スタートアップに、早期顧客へ到達できるシグナルがあるかどうか。
2. ICP — 購入者、職務、きっかけ、除外条件。
3. 最有力候補 — 最も強い根拠がある候補と、なぜ今なのか。
4. 候補リスト — 安定したID、ソース／日付、スコア、今である理由、対象となる役職、確認済みの連絡経路（または見つからない経路）、具体的な次のステップ、CTA、書き出し、注意事項。
5. 繰り返し現れるパターン — 複数の候補に共通する課題ときっかけ。
6. 7日間のアウトリーチ計画 — 手動で実施する、少数に絞った検証の手順。
7. 制限事項 — 不足している証拠と、実際の会話を通じて確認すべきこと。

デフォルトでは、ネイティブの Markdown レポートと CSV を作成します。単体の HTML オプションも維持し、依頼された場合は生成します。チャットのみ、または指定された形式の希望を尊重します。

1. references/report-artifact.md を使って構造化 JSON を作成します。
2. 明示的な出力パスを指定し、拒否されない限りプロダクトのローカル状態パスも指定して、同梱のジェネレーターを実行します。ジェネレーターはスコアを計算し、v2 データを検証して、Markdown／CSV／任意の HTML をエクスポートし、コンパクトな履歴を保存します。以前のレポートが保持されるよう、新しい実行フォルダーを使います。
3. レポート、引用、実際に含まれている候補数、連絡経路、文案を確認します。CSV のエクスポートによって何かが送信されたり、CRM と同期されたりすることはありません。
4. Markdown ファイルへの絶対パスのリンクを返します。Codex のファイルを開くツールが利用可能な場合は、現在のタスクでレポートを開きます。他のインストール環境では、そのツールを必須にしないでください。
5. 表示された ID を使って、短いフィードバックを促します。例：「P1 と P3 は適合します。エンタープライズの購入者は避けてください。」フィードバックを待って最初のレポートを遅らせてはいけません。

7. ユーザーの返答に応じて絞り込む

明示的な「残す／保留／却下」のフィードバックは、その理由とともに保存します。明示された全般的な好みは更新後の検索条件に反映し、新たな検索を始める前に変更点を伝えます。1社を却下しただけで、その業界全体を除外するルールにしてはいけません。その違いが重要かどうか、簡潔に尋ねます。「学習」とは、目に見える形でローカルの好みが更新されることであり、モデルのトレーニングではありません。

新たな候補を求められた場合は、--new-only を使用し、製品の対象範囲を維持したうえで、以前に確認したエンティティと、連絡済みまたは却下済みの記録を除外します。代わりに更新を求められた場合は、保存済みの情報源を再検証します。連絡済み、返信あり、顧客のいずれかとしてマークするのは、ユーザーがその結果を伝えた場合に限ります。下書きの生成を、相手への連絡として扱ってはいけません。通常のフォローアップ検索から、定期モニターを開始してはいけません。

モード

• quick：有望な候補を最大5件見つけ、適格性を確認します。
• standard：複数の公開情報源から候補を最大10件見つけます。
• deep：候補を最大20件調査し、繰り返し見られる課題のパターンを整理します。
• design-partners：すぐに購入する人よりも、テストとフィードバックに応じるユーザーを優先します。
• b2b：企業、公開されているビジネス上の動き、関連する意思決定者の役職を優先します。
• community：公開された議論と、明示的な要望のシグナルを優先します。

デフォルトでは standard を使用します。

品質基準

• 各候補を、少なくとも1つの有意義な公開シグナルに結び付けます。
• 一般的な候補を大量に並べるより、有望な候補を10件提示します。
• 不確実性や古くなった証拠を明示します。
• 作り上げた推測ではなく、情報源に基づいてパーソナライズします。
• アウトリーチは手動で行い、相手に配慮します。
• 候補リストは調査上の仮説として扱い、顧客データベースとして扱いません。
• ローカルの履歴や調査結果を、スキルリポジトリや npm パッケージに含めないでください。デモ用のフィクスチャは、すべての出力形式で架空の情報であることを明示します。