Event Prospecting

カンファレンス URL を入力 → 営業担当者が話すべき人物のランク付けリストを取得し、各人物ごとに「アウトリーチ理由」を記載します。

必須: BROWSERBASE_API_KEY 環境変数、bb CLI インストール (@browserbasehq/cli)、JavaScript が多いスピーカーページ用の browse CLI インストール (@browserbasehq/browse-cli) (ほとんどのモダンイベントサイト)。

パスルール: すべての Bash コマンドで完全リテラルパスを常に使用 — ~ または $HOME は使用しない (どちらもシェル展開構文承認プロンプトをトリガーします)。ホームディレクトリを一度解決してすべての場所で使用します。サブエージェントプロンプトを構築する場合、{SKILL_DIR} を完全リテラルパス (通常 /Users/jay/skills/skills/event-prospecting) に置き換えます。

出力ディレクトリ: すべてのイベントプロスペクティング出力は ~/Desktop/{event_slug}_prospects_{YYYY-MM-DD-HHMM}/ に保存されます。最終成果物は index.html (企業別にグループ化、企業 ICP でランク付け) で、companies.html と people.html (フィルタリング可能) が代替ビュー、results.csv がコールドアウトバウンド用です。

重要 — ツール制限 (メインエージェント AND すべてのサブエージェントに適用):

• すべてのウェブ検索: bb search を使用。WebSearch は使用しない。
• すべてのページコンテンツ抽出: node {SKILL_DIR}/scripts/extract_page.mjs "<url>" を使用。このスクリプトは bb fetch でフェッチ、title + meta タグ + 表示テキストをパース、ページが JS レンダリングまたは 1MB 超過時に自動的に bb browse にフォールバック。手書きの bb fetch | sed パイプラインは使用しない。WebFetch は使用しない。
• すべての調査出力: サブエージェントは bash heredoc を使用して {OUTPUT_DIR}/companies/{slug}.md または {OUTPUT_DIR}/people/{slug}.md に 企業ごと OR 人物ごとに 1 つのマークダウンファイル を書き込み。Write ツールまたは python3 -c は使用しない。references/example-research.md を参照して両方のファイル形式を確認。
• レポートコンパイル: node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --open を使用。
• サブエージェントは Bash ツールのみ使用。他のツールは許可されません。
• 厳しいツール呼び出し上限: ICP 分類 = 1 呼び出し/企業; 詳細調査 = 5 呼び出し/企業; 人物エンリッチメント = 4 呼び出し/人物。references/workflow.md で実装詳細を確認。

重要 — ハルシネーション防止ルール (メインエージェント AND すべてのサブエージェントに適用):

• サイトのフォント、フレームワーク、デザインシステム、タイポグラフィから product_description、industry、または人物の role_reason を推測しない。これらは見た目に関するものであり、企業が何を販売しているか、その人物が何をしているかについては何も言いません。
• ユーザー自身の ICP がターゲットの説明に漏れないようにする。ターゲットが何をしているかわからない場合は、Unknown と書き、ICP にパターンマッチングしない。
• product_description は extract_page.mjs 出力から特定のフレーズを引用またはパラフレーズする必要があります。TITLE/META/OG/HEADINGS/BODY のいずれからも認識可能な製品ステートメントが得られない場合は、Unknown — homepage content not accessible と書き、icp_fit_score を 3 以下に制限します。
• 人物の hook は bb search 結果 (ポッドキャストタイトル、ブログ見出し、GitHub リポジトリ、トーク概要) からの特定の発見を引用またはパラフレーズする必要があります。過去 6 ヶ月内に公開信号が存在しない場合、イベント文脈にフォールバック (このイベントでのトークタイトル)。

重要 — 許可プロンプトを最小化:

• サブエージェントは連鎖 heredocs を使用してすべてのファイル書き込みを SINGLE Bash 呼び出しにバッチ。1 つの Bash 呼び出し = 1 つの許可プロンプト。
• && チェーンを使用してすべての検索とすべてのフェッチを単一 Bash 呼び出しにバッチ。

パイプラインの概要

以下の 10 ステップを順番に従います。ステップをスキップまたは並べ替えない。

0. セットアップ — 出力ディレクトリ + クリーンスレート
1. プロファイルをロード — profiles/{user_slug}.json を読む
2. 偵察 — イベントプラットフォームを検出
3. 人物を抽出 — people.jsonl
4. 企業でグループ化 — seed_companies.txt
5. ICP 分類 — 高速な企業レベルスコアリング (企業あたり 1 呼び出し)
6. フィルタリング — icp_fit_score >= --icp-threshold の企業
7. 詳細調査 — ICP 適合に対する完全な Plan→Research→Synthesize
8. スピーカーをエンリッチ — ユーザーに質問: ICP 適合のみ (デフォルト) または全スピーカー
9. レポートをコンパイル — HTML + CSV、ブラウザで開く

ユーザーは /event-prospecting <URL> のようなスキルを呼び出します。その呼び出しメッセージから EVENT_URL を解析します。デフォルト: DEPTH=deep、ICP_THRESHOLD=6。USER_SLUG (ICP プロファイル) はステップ 1 で存在するプロファイルファイルから自動解決されます — 組み込みデフォルトプロファイルはありません。ユーザーが URL を確認するよう求めない — 既に提供しています。

---

ステップ 0: 出力ディレクトリセットアップ

ユーザーが指定した URL から出力ディレクトリを導出。イベント名はハードコードしない。

# EVENT_URL は呼び出しメッセージから来ています (ユーザーが `/event-prospecting` の後に入力したもの)
EVENT_SLUG=$(node -e 'const h = new URL(process.argv[1]).hostname.replace(/^www\./,""); console.log(h.split(".")[0])' "$EVENT_URL")
TIMESTAMP=$(date +%Y-%m-%d-%H%M)
OUTPUT_DIR=/Users/jay/Desktop/${EVENT_SLUG}_prospects_${TIMESTAMP}
mkdir -p "$OUTPUT_DIR/companies" "$OUTPUT_DIR/people"

完全リテラルホームパスを使用 — ~ または $HOME は使用しない。すべてのサブエージェントプロンプトに完全リテラルパスとして {OUTPUT_DIR} を渡します。

ステップ 1: ユーザープロファイルをロード

プロファイルは ICP 分類と詳細調査がスコアを付与する ICP を定義します。{SKILL_DIR}/profiles/{user_slug}.json からロード (すべての GTM スキル全体で相互運用可能 — company-research と同じ形状)。example.json はテンプレートであり実際のプロファイルではない — 使用しない。

{SKILL_DIR}/profiles/ の外を見ない — 他のスキルのディレクトリには到達しない。プロファイルが他の場所で必要な場合、ユーザーは明示的にコピーします。

解決順序:

1. ユーザーが --user-company <slug> で呼び出した場合、そのスラッグを使用。
2. そうでなければ、profiles/*.json をリスト (example.json を除外)。正確に 1 つのプロファイルが存在する場合、それを使用 (ユーザーにどれを使用しているかを伝える)。複数存在する場合、ユーザーに質問 (プレーンチャット) してどれを選択するか。
3. ゼロプロファイルが存在する場合、大きく失敗 してユーザーに 1 つを作成するよう指示 (profiles/example.json を profiles/<your_slug>.json にコピーして入力するか、company-research スキルを実行して自動構築)。

PROFILES=$(ls {SKILL_DIR}/profiles/*.json 2>/dev/null | xargs -n1 basename | sed 's/\.json$//' | grep -v '^example$')
COUNT=$(echo "$PROFILES" | grep -c .)

if [ -z "$USER_SLUG" ]; then
  if [ "$COUNT" -eq 0 ]; then
    echo "No profiles found in {SKILL_DIR}/profiles/. Copy profiles/example.json to profiles/<your_slug>.json and fill it in, or run the company-research skill to build one."
    exit 1
  elif [ "$COUNT" -eq 1 ]; then
    USER_SLUG=$PROFILES
    echo "Using the only profile available: ${USER_SLUG}"
  else
    echo "Multiple profiles found:"
    echo "$PROFILES" | sed 's/^/  - /'
    echo "Re-invoke with --user-company <slug> to pick one."
    exit 1
  fi
fi

test -f {SKILL_DIR}/profiles/${USER_SLUG}.json || {
  echo "Profile not found: profiles/${USER_SLUG}.json"
  exit 1
}
cat {SKILL_DIR}/profiles/${USER_SLUG}.json

プロファイルは次を生成: company、product、icp_description、existing_customers。これらはすべてのダウンストリームサブエージェントプロンプトに逐語的に埋め込まれます。

ステップ 2: 偵察

イベントプラットフォームと抽出戦略を検出。1 つのコマンド:

node {SKILL_DIR}/scripts/recon.mjs {EVENT_URL} {OUTPUT_DIR}

{OUTPUT_DIR}/recon.json を書き込み、platform、strategy、(Next.js 用) nextDataPaths。プラットフォームカタログと検出優先度は references/event-platforms.md を参照。

予想される結果:

• Stripe Sessions クラス (Next.js): platform: "next-data"、1-3 パス
• Sessionize: platform: "sessionize"
• Lu.ma / Eventbrite: platform: "luma" | "eventbrite"
• その他: platform: "custom"、strategy: "markdown" (ベストエフォート フォールバック)

ステップ 3: 人物を抽出

node {SKILL_DIR}/scripts/extract_event.mjs {OUTPUT_DIR} --user-company {USER_SLUG}

recon.json を読み込み、プラットフォーム固有の抽出器にディスパッチ、people.jsonl (1 行に 1 スピーカー) と seed_companies.txt (重複排除済み企業) を書き込み。

--user-company フラグはホスト組織の従業員 (Stripe ホストイベントは Stripe 従業員を削除) とユーザーの従業員をスピーカーリストから削除 — それらはプロスペクトではありません。

出力をサニティチェック:

wc -l {OUTPUT_DIR}/people.jsonl {OUTPUT_DIR}/seed_companies.txt
head -3 {OUTPUT_DIR}/people.jsonl

people.jsonl が空または約 10 行未満の場合、偵察が誤ったプラットフォームを選択 — references/event-platforms.md を参照して調整された戦略で再実行。

ステップ 4: 企業でグループ化

extract_event.mjs は既に seed_companies.txt を出力 (1 行に 1 企業、重複排除済み、ソート済み)。このステップは情報提供のみ — ファンアウト前に数が適切に見えることを確認:

wc -l {OUTPUT_DIR}/seed_companies.txt

予想: 大約スピーカー数の 0.4-0.6 倍 (ほとんどのイベントは平均 1 企業あたり約 2 スピーカー、企業によっては 5 以上、多くは 1)。

ステップ 5: ICP 分類

高速パス — 企業あたり 1 ツール呼び出し、詳細調査なし。 seed_companies.txt のすべての企業をユーザーの ICP に対してスコアリングして、companies/{slug}.md に薄い分類スタブを書き込み。icp_fit_score >= --icp-threshold (デフォルト 6) の企業はステップ 7 の詳細調査に進む; その他は分類スタブのままです。

ディスパッチパターン: seed_companies.txt を約 10 の企業のバッチに分割して、SINGLE Agent バッチで N サブエージェントをファンアウト (複数の Agent ツール呼び出しを 1 つのメッセージで)。各サブエージェントは references/workflow.md → "ICP Triage" セクションのプロンプトを実行。ハード上限: 企業あたり 1 ツール呼び出し (ホームページで extract_page.mjs のみ)、# bb call N/1 コメントパターンで実装。

# バッチファイルを構築: 各行は "name|guessed_homepage|slug"。
# extract_event.mjs は企業名のみを出力 (URL なし) ため、スラッグ化して
# https://{slug-without-spaces}.com を正規ホームページとして推測。分類サブエージェントは
# product_description を "Unknown — homepage content not accessible" と書き込み可能
# かつ推測 URL が 404 の場合スコアを 3 に制限 — これは workflow.md で記載されたフォールバック
# (ICP Triage プロンプトのルール 3)。実 bb search を URL 発見に使用するとハード上限
# 1 呼び出し/企業を破します。
node -e '
const fs = require("fs");
const slugify = (s) => (s || "").toLowerCase().replace(/[^a-z0-9]+/g, "-").replace(/^-+|-+$/g, "");
const seed = fs.readFileSync("{OUTPUT_DIR}/seed_companies.txt", "utf-8").split("\n").filter(Boolean);
const lines = seed.map(c => {
  const slug = slugify(c);
  const guessedHost = c.toLowerCase().replace(/[^a-z0-9]/g, "");
  return `${c}|https://${guessedHost}.com|${slug}`;
});
fs.writeFileSync("{OUTPUT_DIR}/_seed_with_urls.txt", lines.join("\n") + "\n");
'

# 約 10 企業のバッチに分割
split -l 10 {OUTPUT_DIR}/_seed_with_urls.txt {OUTPUT_DIR}/_batch_triage_

# バッチ数をカウント → ディスパッチするサブエージェント数 (メッセージあたり最大 6; 残りは第 2 波)
ls {OUTPUT_DIR}/_batch_triage_* | wc -l

その後、1 つのメッセージで、バッチあたり 1 つの Agent 呼び出しをディスパッチ (最大 6 並列; 最初が返った後に後続の波)。各 Agent は送信前に以下の置換を持つ references/workflow.md → "ICP Triage" からプロンプトを取得:

• {SKILL_DIR} → 完全リテラルスキルパス (例: /Users/jay/skills/skills/event-prospecting)
• {OUTPUT_DIR} → 完全リテラル出力パス
• {USER_COMPANY}、{USER_PRODUCT}、{ICP_DESCRIPTION} → ロード済みプロファイルから
• {EVENT_NAME} → recon.json .title から
• {COMPANY_LIST} → バッチファイルの内容 (例: cat {OUTPUT_DIR}/_batch_triage_aa)
• {TOTAL} → このバッチの行数 (置換して # bb call N/{TOTAL})

Agent ディスパッチ (スケルトン、メッセージ内のバッチごとに繰り返し):

Agent(
  description: "ICP triage batch aa",
  prompt: <すべてのプレースホルダが置換された workflow.md の ICP Triage プロンプト>,
  subagent_type: "general-purpose"
)
Agent(
  description: "ICP triage batch ab",
  prompt: <同じプロンプトテンプレート、COMPANY_LIST をバッチ ab に交換>,
  subagent_type: "general-purpose"
)
... メッセージあたり最大 6

すべてのサブエージェントが返った後、seed_companies.txt のすべての企業に対応する companies/{slug}.md があることを確認:

ls {OUTPUT_DIR}/companies/*.md | wc -l
# `wc -l {OUTPUT_DIR}/seed_companies.txt` と等しいはず

バッチファイルをクリーンアップ: rm {OUTPUT_DIR}/_batch_triage_*.

ステップ 6: ICP 閾値でフィルタリング

各 companies/*.md フロントマターを読み込み、icp_fit_score >= 6 (または --icp-threshold で指定されたもの) のものを保持。生き残った企業スラッグを {OUTPUT_DIR}/icp_fits.txt に書き込み:

THRESHOLD=6   # from --icp-threshold flag
for f in {OUTPUT_DIR}/companies/*.md; do
  score=$(awk '/^icp_fit_score:/{print $2; exit}' "$f")
  if [ -n "$score" ] && [ "$score" -ge "$THRESHOLD" ]; then
    basename "$f" .md
  fi
done > {OUTPUT_DIR}/icp_fits.txt

wc -l {OUTPUT_DIR}/icp_fits.txt

予想: seed_companies.txt の 20-40%。生存率が < 10% の場合、閾値が高すぎるか ICP 説明が狭すぎる可能性 — ユーザーに警告を表示。

ステップ 7: 詳細調査

ICP 適合企業のみに対する完全な Plan→Research→Synthesize。ハード上限: 企業あたり 5 ツール呼び出し (ホームページ抽出 + 2-3 サブ質問検索 + 1-2 補足フェッチ)。サブエージェントは既存の companies/{slug}.md 分類スタブを よりリッチな詳細調査版で上書き (フロントマター triage_only: false)。

ディスパッチパターン: icp_fits.txt を約 5 企業のバッチに分割 (詳細モードデフォルト) してSINGLE メッセージで企業あたり 1 つの Agent をファンアウト (メッセージあたり最大 6 Agents)。各 Agent は references/workflow.md → "Deep Research" からプロンプトを取得、以下の置換を含む:

• {SKILL_DIR}、{OUTPUT_DIR}、{USER_COMPANY}、{USER_PRODUCT}、{ICP_DESCRIPTION}
• {EVENT_NAME} (recon.json の .title から)、{EVENT_CONTEXT} (トラック / トピック、イベントホームページから手動で推測)
• {COMPANY_LIST} → バッチファイルの内容 (各行 slug|website)

# 各分類スタブからフロントマターを読んで {company-slug|website} ペアを構築
while read slug; do
  website=$(awk '/^website:/{print $2; exit}' {OUTPUT_DIR}/companies/${slug}.md)
  echo "${slug}|${website}"
done < {OUTPUT_DIR}/icp_fits.txt > {OUTPUT_DIR}/_deep_targets.txt

# 約 5 企業のバッチに分割 (詳細モード)
split -l 5 {OUTPUT_DIR}/_deep_targets.txt {OUTPUT_DIR}/_batch_deep_
ls {OUTPUT_DIR}/_batch_deep_* | wc -l

Agent ディスパッチ (スケルトン、メッセージ内のバッチごとに繰り返し):

Agent(
  description: "Deep research batch aa",
  prompt: <すべてのプレースホルダが置換された workflow.md の Deep Research プロンプト; COMPANY_LIST = cat _batch_deep_aa>,
  subagent_type: "general-purpose"
)
Agent(
  description: "Deep research batch ab",
  prompt: <同じテンプレート、COMPANY_LIST = cat _batch_deep_ab>,
  subagent_type: "general-purpose"
)
... メッセージあたり最大 6; 最初が返った後に第 2 波

すべてのサブエージェントが返った後、詳細調査ファイルが存在し triage_only: false を持つことを確認:

grep -l "triage_only: false" {OUTPUT_DIR}/companies/*.md | wc -l
# `wc -l icp_fits.txt` と等しいはず

ステップ 8: スピーカーをエンリッチ

人物あたり: LinkedIn URL、最近のアクティビティ (ポッドキャスト / ブログ / トーク / GitHub / X) を収集し、people/{slug}.md を書き込み。ハード上限: 人物あたり 4 ツール呼び出し、3 ロック:

1. bb search "{name} {company} linkedin" (常に)
2. bb search "{name} podcast OR talk OR blog 2026" (deep+)
3. bb search "{name} github" (deeper)
4. bb search "{name} site:x.com OR site:twitter.com" (deeper)

Quick モード: ステップ 8 を完全スキップ。Deep モード: ロック 1-2。Deeper モード: ロック 1-4。

ステップ 8a — ユーザーに質問: エンリッチメントの範囲

ディスパッチする前に、2 つの候補数を計算し、ユーザーに選択を求める。デフォルトは ICP 適合のみ (高速、安価、ほとんどのユーザーが望むもの); すべてのスピーカーをエンリッチするのはコストが人数に線形にスケールするため opt-in です。

TOTAL=$(wc -l < {OUTPUT_DIR}/people.jsonl)
ICP_FITS=$(node -e '
const fs = require("fs");
const fits = new Set(fs.readFileSync("{OUTPUT_DIR}/icp_fits.txt", "utf-8").split("\n").filter(Boolean));
const slug2name = {};
for (const slug of fits) {
  const md = fs.readFileSync(`{OUTPUT_DIR}/companies/${slug}.md`, "utf-8");
  const m = md.match(/^company_name:\s*(.+)$/m);
  if (m) slug2name[slug] = m[1].trim();
}
const want = new Set(Object.values(slug2name).map(s => s.toLowerCase()));
const ppl = fs.readFileSync("{OUTPUT_DIR}/people.jsonl","utf-8").split("\n").filter(Boolean).map(JSON.parse);
console.log(ppl.filter(p => p.company && want.has(p.company.toLowerCase())).length);
')

# ロック数/人物: 2 (deep) または 4 (deeper) — {DEPTH} と一致
LANES=2   # または deeper の場合 4
echo "ICP fits: ${ICP_FITS} speakers × ${LANES} = $((ICP_FITS * LANES)) calls"
echo "All:      ${TOTAL} speakers × ${LANES} = $((TOTAL * LANES)) calls"

その後 AskUserQuestion 経由で質問 — 各オプションで定量化されたコストを含む明確な 2 オプション選択:

AskUserQuestion(questions: [
  {
    question: "Enrich which speakers?",
    header: "Enrichment scope",
    multiSelect: false,
    options: [
      { label: "ICP fits only", description: "${ICP_FITS} speakers, ~$((ICP_FITS * LANES)) calls (recommended)" },
      { label: "All speakers", description: "${TOTAL} speakers, ~$((TOTAL * LANES)) calls" }
    ]
  }
])

選択した範囲を ENRICH_SCOPE=icp_fits または ENRICH_SCOPE=all として保存。ユーザーが「All speakers」を選択し TOTAL × LANES > 600 の場合、警告を印字して再度質問 — それは 10 分以上の実行時間で数百のツール呼び出し。

ステップ 8b — フィルタリングとバッチ

# ENRICH_SCOPE に基づいて _people_to_enrich.jsonl を構築
if [ "$ENRICH_SCOPE" = "all" ]; then
  cp {OUTPUT_DIR}/people.jsonl {OUTPUT_DIR}/_people_to_enrich.jsonl
else
  node -e '
const fs = require("fs");
const fits = new Set(fs.readFileSync("{OUTPUT_DIR}/icp_fits.txt", "utf-8").split("\n").filter(Boolean));
const slug2name = {};
for (const slug of fits) {
  const md = fs.readFileSync(`{OUTPUT_DIR}/companies/${slug}.md`, "utf-8");
  const m = md.match(/^company_name:\s*(.+)$/m);
  if (m) slug2name[slug] = m[1].trim();
}
const wantNames = new Set(Object.values(slug2name).map(s => s.toLowerCase()));
const lines = fs.readFileSync("{OUTPUT_DIR}/people.jsonl", "utf-8").split("\n").filter(Boolean);
const keep = lines.filter(l => {
  const p = JSON.parse(l);
  return p.company && wantNames.has(p.company.toLowerCase());
});
fs.writeFileSync("{OUTPUT_DIR}/_people_to_enrich.jsonl", keep.join("\n") + "\n");
console.error(`Enriching ${keep.length} of ${lines.length} speakers`);
'
fi

# 約 5 人のバッチに分割
split -l 5 {OUTPUT_DIR}/_people_to_enrich.jsonl {OUTPUT_DIR}/_batch_people_

その後、1 つのメッセージで references/workflow.md → "Person Enrichment" のプロンプトを持つバッチあたり 1 つの Agent 呼び出しをディスパッチ (メッセージあたり最大 6)。各サブエージェントのプロンプトに含める:

• {SKILL_DIR}、{OUTPUT_DIR}、{DEPTH} (deep | deeper)
• {USER_COMPANY}、{USER_PRODUCT}、{ICP_DESCRIPTION}
• {EVENT_NAME} (recon.json の .title から)
• {LANES} → deep モード時 2、deeper モード時 4 (# bb call N/{LANES} に置換)
• {PEOPLE_BATCH} → _batch_people_aa の内容 (各行は people.jsonl からの JSON レコード)

Agent ディスパッチ (スケルトン、メッセージ内のバッチごとに繰り返し):

Agent(
  description: "Person enrichment batch aa",
  prompt: <すべてのプレースホルダが置換された workflow.md の Person Enrichment プロンプト; PEOPLE_BATCH = cat _batch_people_aa>,
  subagent_type: "general-purpose"
)
Agent(
  description: "Person enrichment batch ab",
  prompt: <同じテンプレート、PEOPLE_BATCH = cat _batch_people_ab>,
  subagent_type: "general-purpose"
)
... メッセージあたり最大 6

すべてのサブエージェントが返った後、人物ファイルが存在することを確認:

ls {OUTPUT_DIR}/people/*.md | wc -l
# `wc -l _people_to_enrich.jsonl` と等しいはず

ステップ 9: レポートをコンパイル

1 つのコマンドで企業グループ化 HTML インデックス、代替ビュー、CSV を生成:

node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --open

これは次を生成:

• {OUTPUT_DIR}/index.html — 企業別にグループ化されたピープル、企業 ICP スコアでランク付け (ブラウザで開く)
• {OUTPUT_DIR}/people.html — フィルタリング可能なスピーカーリスト (代替ビュー)
• {OUTPUT_DIR}/companies.html — ICP ランク付けされた企業テーブルと出席者
• {OUTPUT_DIR}/results.csv — コールドアウトバウンド対応スプレッドシート

その後、チャットで概要を提示:

## Event Prospecting Complete — {Event Name}

- **Total speakers extracted**: {count}
- **Unique companies**: {count}
- **ICP fits (score ≥ {threshold})**: {count}
- **Speakers enriched**: {count}
- **Score distribution** (companies):
  - Strong fit (8-10): {count}
  - Partial fit (5-7): {count}
  - Weak fit (1-4): {count}
- **Report opened in browser**: {OUTPUT_DIR}/index.html

企業 ICP スコアでソートされた 上位 5 人物カード をマークダウンテーブルとして表示。次を提案:

• --icp-threshold を調整してステップ 6-9 を再実行
• CSV を CRM にエクスポート