karthikselvarjn/lead-signal-scout

Lead Signal Scout

製品のURLを、エージェントが開封し、読み、日付を記録したページに載っているエントリのみで構成されるショートリストに変換します。未確認、古い、または不適格な見込み客がショートリストに含まれることはありません。

6つのゲートは必須です。1つでもスキップすると実行は無効になります。その場合は出力を出すのではなく、その旨を伝えてください。

1. インテーク（ステップ1）- ブリーフが弱いマッチを却下できるようになるまで、リサーチを開始しないでください。
2. 検証（ステップ4）- 見込み客のページを取得していないのに、その見込み客の記述を作成しないでください。
3. スクリーニング（ステップ4）- 結果を出したクエリを、そのうちの1つを実際に開いて理由を書き留めることなく放棄しないでください。
4. 新しさ（ステップ5）- 日付がない、または期限を過ぎたシグナルをショートリストに加えないでください。
5. 適格性（ステップ6）- 自らの問題を示す証拠がない、購入能力がない、利用可能な連絡手段がない、または企業重視モードで企業が特定されていない見込み客をショートリストに加えないでください。
6. 監査（ステップ8）- validate_run.py が PASS を返すまで結果を提示しないでください。

すべての散文フィールドは references/writing-rules.md に従って記述してください。生成されたように読めるレポートは、その背後にあるリサーチがどんなに優れていても無視されます。

ワークフロー

1. インテーク

references/intake.md を読んでください。製品ブリーフを作成し、ランディングページだけではわからない4つの事項（地理、価格帯 および購買モーション、除外事項、既存顧客や過去の受注データ）を、1回のバッチメッセージで一度だけユーザーに尋ねてください。ユーザーが回答しない場合は、ラベル付きの仮定を付けて進めてください。

icp.price_band_source を user または assumed として記録してください。これは重要です。あなたが発明したバンドは、誰かを除外する権限を持ちません。 assumed の場合、commercial_fit を価格理由で3未満にスコアリングしないでください。誰も確認していない数値が、どの実際の企業をドロップするかを決める権限はありません。

max_age_days はここで設定します。デフォルトは120です。シグナルが採用投稿やベンダー検索になる場合は60を使用してください。4ヶ月前のリクエストはほぼ確実にすでに充足されています。

2. モードと深さの設定

モードは何を最適化するかを決定します。深さは数を決定します。これらは独立しています。

モード	最適化対象	重み（ペイン / 適合 / 商業 / タイミング / リーチ / 証拠）
discovery (デフォルト)	満たされていないペイン、プロダクトマーケットフィット以前	28 / 22 / 10 / 14 / 13 / 13
pipeline	営業中のビジネス向けの反復可能なリードフロー	22 / 20 / 20 / 14 / 12 / 12
design-partners	テストしてフィードバックをくれる可能性が高い人々	24 / 18 / 6 / 10 / 24 / 18
b2b	現在のビジネストリガーを持つ企業	14 / 20 / 26 / 18 / 11 / 11
community	明示的な公開リクエストやディスカッション	28 / 18 / 8 / 14 / 22 / 10

b2b と pipeline モードでは、企業が特定されていない見込み客をショートリストに加えることを拒否します。

深さ	ショートリスト上限	最低クエリ数	最低開封ページ数	最低バケット x ファミリーカバレッジ
quick	5	10	12	4 バケット x 3 ファミリー
standard (デフォルト)	10	18	20	5 バケット x 4 ファミリー
deep	20	35	35	7 バケット x 6 ファミリー

クエリはタイピング量を、ページは読み取り量を測定します。そして、そのうちの1つだけが顧客を見つけます。開封したページ（候補にならなかったページも含む）の数を coverage.pages_opened に記録してください。

選択したモードのプロファイルをそのまま実行JSONにコピーしてください。監査人はそれに対してすべてのスコアを再計算し、宣言された重みがモードのプロファイルからずれている場合は失敗します。

3. 検索の計画と実行

references/search-playbook.md を読んでください。検索前にクエリ計画を書いてください。どのバケット、どのソースファミリー、どのような言い回しをオーディエンス自身の言葉で使うかを決めます。すべてのクエリとその結果数（ゼロ結果のものも含む）を記録してください。候補URLを収集します。まだ見込み客レコードは作成しないでください。

4. 書き込む前に検証する

references/verification.md を読んでください。各候補URLをフェッチし、その後で判断します。

• signal_confirmed - ページをフェッチし、そこにシグナルが存在し、指名された見込み客に帰属する。これのみショートリストに追加可能。
• url_ok - フェッチしたが、シグナルが曖昧、帰属が推測、または日付がない。レビュー対象。
• unverified - フェッチしていない、リンク切れ、または有料壁の背後にある。理由とともに dropped に追加し、停止する。レコードを作成しないでください。

完全な見込み客レコードを書いてから、ページが404エラーだったために破棄するのは、実行の大部分を無駄にします。まずフェッチし、次に書き込みます。

放棄しようとしているものを開けてください。 3つ以上の結果を出したにもかかわらず1つも保持しなかったクエリは、そのカバレッジエントリに note が必要で、その結果の1つを開いた後に記述します。監査人は、放棄されたクエリのほとんどにメモがない場合、実行を失敗とします。

このステップこそが誰がショートリストに載るかを決定しますが、書き留めなければ見えません。16のクエリを記録し、すべてのカバレッジ基準をクリアした実行でも、75の結果を出し、10を開き、そのショートリスト全体を3つのアナウンス型クエリから取っている可能性があります。一方で、競合のレビューのページや3つの公開RFPは読まれていないかもしれません。監査ラインはそれをフルカバレッジと呼びます。ソースだけでなく連絡手段も検証してください。verification.md に記録すべき内容が記載されています。

リサーチの制限: 公開された専門的およびビジネス情報のみ。ログイン、ペイウォール、アクセス制御、レート制限、ロボット制限のバイパスは禁止。データブローカー、漏洩データセット、プライベートグループ、個人メールの発見、電話番号のエンリッチメントも禁止。保護された特性、健康、経済的困難、政治、宗教、性別について推測したりターゲットにしたりしないでください。

5. すべてのシグナルに日付を付ける

タイミングは経過日数からスコアリングされるため、日付のないシグナルはショートリストに追加できません。以下のリストを上から順に確認し、最初に答えが得られたもので停止します。表示されている公開日、ページ上の相対タイムスタンプを signal_age_days に変換したもの、またはURLにエンコードされたタイムスタンプ。どれを使用したかを date_basis に記録してください。verification.md にそれぞれの方法が記載されています。

経過日数を決して推定しないでください。2026-08 のような部分的な日付は拒否され、未来の日付も拒否されます。推測された日付に基づくショートリストエントリは、まさにこのスキルが防止しようとしている失敗です。

確認されたすべての見込み客に対して fetched_at と final_url を記録してください。監査人はあなたがページをフェッチするのを見ることはできません。これらの記録は、裏付けのない主張をするためにより多くの労力を必要とします。

6. スコアリング、ゲート、重複排除

references/scoring.md を読んでください。6つのディメンションを0-5で、記述されたアンカーに対してスコアリングします。タイミングは経過日数から算出され、バンドによって上限が決まります。指名された現在のトリガーがある場合は上限が1つ上がります。

pain_strength は 見込み客自身の問題、つまり製品が解決する仕事について、彼らの言葉でスコアリングします。彼らの顧客が抱える問題、彼らがその解決策を販売している問題、または彼らがコメントした市場トレンドはすべて0点です。すべての消費者ブランドがキャンペーンを開始します。それはシグナルではありません。

commercial_fit は、この売り手が、この買い手を、売り手が持っている購買モーションを通じて成約できるか を尋ねます。企業が大規模かどうかではありません。数十億の収益、100カ国、公開されたサプライヤポータルは調達キューが存在する証拠であり、セルフサービスまたは創業者主導の売り手にとっては4点ではなく2点です。

50未満のものはドロップします。日付がないもの、max_age_days より古くて3つの still_open フィールドがないもの、pain_strength が0または1で名前付き trigger がないもの、ユーザー提供のバンドに対して commercial_fit が0または1のもの、唯一の連絡手段が inappropriate であるもの、b2b または pipeline モードで企業が特定されていないものをレビュー対象に回します。何も削除されません。レビュー対象にはそれぞれ理由とともに表示されます。

単一のインテントラベルではなく、signal_type と purchase_readiness を記録します。デザイナーを雇用している人は、実際に意図はありますがソフトウェアを購入する意図はありません。2つのラベルには、その下のディメンションに結びついた上限があります。hiring は adjacent を超えられません。ペインベースのシグナルが strong となるには pain_strength が3必要です。strong には commercial_fit が3必要で、direct には4が必要です。監査人はこれらすべてを強制します。なぜなら、自由記述フィールドが一緒に上昇することこそが、ローンチアナウンスを高インテントのバイヤーに変えてしまう方法だからです。

フリーランサー、契約者、または従業員を募集するページは、その仕事が製品とどれだけ正確に一致していても hiring です。彼らは人材を選んでおり、サービスを選んでいるのではありません。求人広告を direct_request として提出すると、その上限を迂回します。これこそが、時給15ドルのフリーランス案件がかつてショートリストのトップになった方法です。兆候はルートが何を求めているかにあります。ポートフォリオ、CV、履歴書、または料金カードを求める場合は雇用。スコープ、価格、納期、またはトライアルを求める場合は購入です。

dedupe_key で重複排除します。同じ出力ディレクトリ内の以前の実行から ledger.json をロードし、すでにそれが浮上したものを除外します。さらに、ユーザーの除外リストにあるものすべてを除外します。

ショートリストをソース間で分散させてください。1つのソースファミリーまたは1つのドメインから半分を超えないようにします。最も信頼性高くフェッチできるサイトが実行を引き継ぎ、単一ソースのショートリストはそのサイトのバイアスを継承します。

ショートリストの60%以上が80点以上を獲得した場合、アンカーが緩く適用されています。再スコアリングしてください。

7. 誰が、どこで、どのように連絡するかを記録する

company、person、handle を分離します。企業は誰が購入するか。人物は誰が投稿したか。ハンドルはプラットフォーム上のユーザー名です。企業が見えない場合、company を not identified に設定し、ハンドルを handle に、プラットフォームが表記する通り（u/name）に入力します。その場合、出力はハンドルで始まります。最初に企業を探してください。投稿者はスレッド、プロフィール、またはリンクでそれを挙げていることがよくあります。

すべての見込み客に channel_url を提供します。ユーザーが実際に連絡を取るために開くページです。多くの場合、ソーススレッドですが、時には問い合わせフォームやプロフィールです。それを開き、channel_evidence を記録します。そのルートが誰のためのものかを示す短い引用またはページ上の見出しです。channel_fit: valid を主張するショートリスト掲載見込み客がこれを欠いていると、監査に失敗します。

サプライヤーおよびベンダー登録ポータルは、せいぜい questionable であり、会話ではなくキューです。応募者、プレス、カスタマーサポートルートは inappropriate です。最初に見つけたルートが間違った形状の場合、その見込み客を諦める前に適切なルートを探すためにあと1回フェッチを行ってください。大規模なサイトはビジネス問い合わせページを埋もれさせ、キャリアページを上位にランク付けします。

監査人は channel_evidence を読みます。URLだけではありません。RedditやLinkedInの求人広告は完璧にクリーンなURLを持ち、「ポートフォリオと最新の履歴書を共有してください」という言葉だけでその正体が明らかになります。これは、どこでホストされていても応募ルートです。

他のページが同じシグナルを示していない限り、additional_source_urls は空のままにしてください。「Also seen at」として表示されるため、問い合わせページをそこに置くことは、存在しない裏付けを主張することになります。

ショートリストに掲載された見込み客ごとに1つのオープナーをドラフトします。90ワード未満で、フェッチしたページのみに基づきます。送信、提出、接続、フォロー、コメント、CRMへの書き込みは、ユーザーが後続のターンで別途許可しない限り行わないでください。

8. 出力の構築と監査

references/output-schema.md を読み、run.json を書き込み、その後以下を実行します。

python3 <skill-dir>/scripts/validate_run.py run.json
python3 <skill-dir>/scripts/build_outputs.py run.json outputs/

<skill-dir> はこのスキル自身のディレクトリ、つまりこの SKILL.md がロードされたディレクトリです。そこから絶対パスを構築してください。ワーキングディレクトリからの相対パスは使用しないでください。ワーキングディレクトリはユーザーのプロジェクトであり、スキルではありません。ホストが ${CLAUDE_SKILL_DIR} を置換する場合、その変数はこのディレクトリそのものです。

すべての ERROR を修正し、PASS と表示されるまで再実行してください。最終的な応答には監査ラインをそのまま記載してください。build_outputs.py は leads.csv（運用リスト）、leads-full.csv（すべてのフィールド）、report.html、brief.md、および更新された ledger.json を書き込みます。run.json をそれらと一緒に真実の源泉として保持してください。

Pythonがない場合：スキーマから手動で brief.md と leads.csv を作成し、監査人のチェックを手作業で行ってください。

9. 報告

応答と brief.md に監査ラインをそのまま返してください。合格した実行では report.html には表示されません。なぜなら、「問題なし」と言う緑のバナーは、誰かが見込み客レポートを開いて読むものではないからです。

次に、評決、トップの見込み客、およびアーティファクトへの絶対パス。検証され日付のあるものでリードしてください。ギャップを可視化してください。

品質基準

• フェッチされたソースがない見込み客は見込み客ではありません。日付がないものはリードではありません。購入できないものはリサーチインタビューです。自身の問題を述べていないものは市場セグメントです。
• 結果を出したが決して開かれなかったものは、実行の実際の出力です。それらを数え、スキップしようとしていたものを開けてください。
• 30人の候補を検討し、誰もショートリストに載せなかった実行は有効な結果です。水増しせずに、そのまま報告してください。
• 10件の検証済みで最新のマッチは、50件の一般的なものより優れています。
• 何も見つからなかったものも、見つかったものだけでなく報告してください。
• ソースからパーソナライズし、決して創作からパーソナライズしないでください。
• すべてに仮説のラベルを付けてください。公開シグナルは同意、興味、または購入意図ではありません。