event-prospecting

イベントの見込み顧客調査

カンファレンスの URL を渡すと、AE が話すべき人物の優先順位付きリストと、各人物への「連絡する理由」が得られます。

必須：BROWSERBASE_API_KEY 環境変数と、インストール済みの browse CLI（npm install -g browse）。API 呼び出しには browse cloud ... を、JavaScript を多用した登壇者ページには browse open / browse get markdown を使用してください。

パスのルール：すべての Bash コマンドで、~ や $HOME ではなく、常に完全なリテラルパスを使用してください（どちらも「shell expansion syntax」の承認プロンプトを表示させます）。ホームディレクトリは一度だけ解決し、すべてのコマンドで同じパスを使用してください。サブエージェントへのプロンプトを作成するときは、{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 も作成します。

重要 — ツールの使用制限（メインエージェントとすべてのサブエージェントに適用）：

• すべての Web 検索には browse cloud search を使用してください。WebSearch は絶対に使用しないでください。
• すべてのページコンテンツの抽出には、node {SKILL_DIR}/scripts/extract_page.mjs "<url>" を使用してください。このスクリプトは browse cloud fetch --output 経由で取得し、タイトル、メタタグ、表示されている本文テキストを解析します。取得に失敗した場合や、JavaScript でレンダリングされたコンテンツが少ない場合は、browse get markdown に自動的にフォールバックします。browse cloud fetch | sed のパイプラインを独自に作成しないでください。WebFetch は絶対に使用しないでください。
• すべての調査結果は、サブエージェントが Bash のヒアドキュメントを使用して、企業または人物ごとに {OUTPUT_DIR}/companies/{slug}.md または {OUTPUT_DIR}/people/{slug}.md に 1 つの Markdown ファイルを書き出してください。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 を参照してください。

重要 — ハルシネーション防止ルール（メインエージェントとすべてのサブエージェントに適用）：

• サイトのフォント、フレームワーク、デザインシステム、タイポグラフィから product_description、industry、人物の role_reason を推測しないでください。これらは外観上の要素であり、企業の販売内容や人物の職務については何も示しません。
• ユーザー自身の ICP をターゲットの説明に反映させないでください。ターゲットが何をしているのかわからない場合は、ICP に無理に当てはめず、Unknown と記載してください。
• product_description には、extract_page.mjs の出力にある具体的な語句を引用または言い換えて含める必要があります。TITLE／META／OG／HEADINGS／BODY のいずれからも判別できる製品説明が見つからない場合は、Unknown — homepage content not accessible と記載し、icp_fit_score を 3 以下にしてください。
• 人物の hook には、browse cloud search の検索結果にある具体的な情報（ポッドキャストのタイトル、ブログの見出し、GitHub リポジトリ、講演の概要）を引用または言い換えて含める必要があります。過去 6 か月以内に公開された情報がない場合は、イベントでの講演タイトルを使ったイベント関連情報に切り替えてください。

重要 — 承認プロンプトを最小限にする：

• サブエージェントは、すべてのファイル書き込みを連結したヒアドキュメントで 1 回の Bash 呼び出しにまとめてください。Bash 呼び出し 1 回につき、承認プロンプトは 1 回です。
• すべての検索と取得は、&& でつないで 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> のような URL を指定してスキルを呼び出します。その呼び出しメッセージから EVENT_URL を解析します。デフォルト値は DEPTH=deep、ICP_THRESHOLD=6 です。USER_SLUG（ICP プロフィール）は、Step 1 でローカルに存在するプロフィールファイルから自動的に解決されます。組み込みのデフォルトプロフィールはありません。URL の確認をユーザーに求めないでください。ユーザーはすでに URL を指定しています。

---

Step 0: 出力ディレクトリのセットアップ

ユーザーが指定した URL から出力ディレクトリを導き出します。イベント名をハードコードしないでください。

# EVENT_URL came from the invocation message (whatever the user typed after `/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} を渡してください。

Step 1: ユーザープロフィールの読み込み

プロフィールでは、ICP トリアージと詳細調査でスコアリングする対象となる ICP を定義します。{SKILL_DIR}/profiles/{user_slug}.json から読み込みます（すべての GTM スキルで共通して使用でき、company-research と同じ形式です）。example.json はテンプレートであり、実際のプロフィールではありません。決して使用しないでください。

プロフィールを {SKILL_DIR}/profiles/ の外から探さないでください。他のスキルのディレクトリにアクセスしてはいけません。別の場所でプロフィールが必要な場合、ユーザーが明示的にコピーします。

解決の優先順位：

1. ユーザーが --user-company <slug> を指定して呼び出した場合、その slug を使用します。
2. それ以外の場合、example.json を除く profiles/*.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 です。これらは後続のすべてのサブエージェントへのプロンプトにそのまま埋め込まれます。

Step 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"（ベストエフォートのフォールバック）

Step 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 を参照し、方法を調整して再実行してください。

Step 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 社ずつのバッチに分割し、1 回の Agent バッチで N 個のサブエージェントを並列実行します（1 つのメッセージ内で複数の Agent ツール呼び出しを行います）。各サブエージェントは references/workflow.md の「ICP Triage」セクションにあるプロンプトを実行します。上限は会社ごとにツール呼び出し 1 回です（ホームページに対する extract_page.mjs のみ）。# browse call N/1 コメントパターンでこれを徹底します。

# Build batch files: each batch line is "name|guessed_homepage|slug".
# extract_event.mjs only emits company NAMES (no URLs), so we slugify and guess
# https://{slug-without-spaces}.com as the canonical homepage. The triage subagent
# is allowed to write product_description: "Unknown — homepage content not accessible"
# and cap score at 3 if the guessed URL 404s — that's the documented fallback in
# workflow.md (rule 3 of the ICP Triage prompt). Burning a real browse cloud search to
# discover the URL would bust the 1-call-per-company HARD CAP.
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");
'

# Split into ~10-company batches
split -l 10 {OUTPUT_DIR}/_seed_with_urls.txt {OUTPUT_DIR}/_batch_triage_

# Count batches → number of subagents to dispatch (cap at 6 per message; second wave for the rest)
ls {OUTPUT_DIR}/_batch_triage_* | wc -l

次に、1 つのメッセージ内でバッチごとに Agent 呼び出しを 1 回ずつディスパッチします（並列実行は最大 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} → このバッチの行数（# browse call N/{TOTAL} に置換）

Agent のディスパッチ（スケルトン。1 つのメッセージ内でバッチごとに繰り返します）：

Agent(
  description: "ICP triage batch aa",
  prompt: <ICP Triage prompt from workflow.md with all placeholders substituted>,
  subagent_type: "general-purpose"
)
Agent(
  description: "ICP triage batch ab",
  prompt: <same prompt template, COMPANY_LIST swapped to batch ab>,
  subagent_type: "general-purpose"
)
... up to 6 per message

すべてのサブエージェントが返ってきたら、seed_companies.txt のすべての会社に対応する companies/{slug}.md があることを確認します。

ls {OUTPUT_DIR}/companies/*.md | wc -l
# Should equal `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 に適合する会社のみを対象に、計画→調査→統合をすべて行います。上限は会社ごとにツール呼び出し 5 回です（ホームページの抽出＋サブクエリ検索 2～3 回＋補足情報の取得 1～2 回）。サブエージェントは既存の companies/{slug}.md のトリアージ用下書きを、より詳細な調査版で上書きします（フロントマターは triage_only: false）。

ディスパッチパターン：icp_fits.txt を約 5 社ずつのバッチに分割し（詳細モードのデフォルト）、1 つのメッセージ内でバッチごとに Agent を 1 つずつ並列実行します（1 メッセージにつき最大 6 Agent）。各 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）

# Build {company-slug|website} pairs by reading frontmatter from each triage stub
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

# Split into ~5-company batches (deep mode)
split -l 5 {OUTPUT_DIR}/_deep_targets.txt {OUTPUT_DIR}/_batch_deep_
ls {OUTPUT_DIR}/_batch_deep_* | wc -l

Agent のディスパッチ（スケルトン。1 つのメッセージ内でバッチごとに繰り返します）：

Agent(
  description: "Deep research batch aa",
  prompt: <Deep Research prompt from workflow.md with all placeholders substituted; COMPANY_LIST = cat _batch_deep_aa>,
  subagent_type: "general-purpose"
)
Agent(
  description: "Deep research batch ab",
  prompt: <same template, COMPANY_LIST = cat _batch_deep_ab>,
  subagent_type: "general-purpose"
)
... up to 6 per message; second wave after the first returns

すべてのサブエージェントが返ってきたら、詳細調査ファイルが存在し、triage_only: false になっていることを確認します。

grep -l "triage_only: false" {OUTPUT_DIR}/companies/*.md | wc -l
# Should equal wc -l icp_fits.txt

ステップ 8：登壇者情報の拡充

人物ごとに、LinkedIn の URL と最近の活動（ポッドキャスト／ブログ／講演／GitHub／X）を収集し、people/{slug}.md に書き込みます。上限は人物ごとにツール呼び出し 4 回です。調査の範囲は 3 段階です。

1. browse cloud search "{name} {company} linkedin"（常に実行）
2. browse cloud search "{name} podcast OR talk OR blog 2026"（詳細モード以上）
3. browse cloud search "{name} github"（より詳細なモード）
4. browse cloud search "{name} site:x.com OR site:twitter.com"（より詳細なモード。可能な範囲で実行）

クイックモード：ステップ 8 全体を省略します。詳細モード：1～2 を実行します。より詳細なモード：1～4 を実行します。

ステップ 8a — ユーザーに確認する：エンリッチメントの範囲

ディスパッチする前に、2 つの候補件数を計算し、ユーザーに選択を求めます。デフォルトは ICP 適合のみ（より高速で安価、ほとんどのユーザーが求めるもの）です。すべての登録者をエンリッチすることはオプトインです。理由は、コストがエンリッチする人数に比例して増加するためです。

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);
')

# Lanes per person: 2 (deep) or 4 (deeper) — match {DEPTH}
LANES=2   # or 4 for deeper
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 — フィルタリングとバッチ処理

# Build _people_to_enrich.jsonl based on ENRICH_SCOPE
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

# Split into ~5-person batches
split -l 5 {OUTPUT_DIR}/_people_to_enrich.jsonl {OUTPUT_DIR}/_batch_people_

次に、1 つのメッセージで、バッチごとに 1 回の Agent 呼び出しを（1 メッセージにつき最大 6 回まで）references/workflow.md → 「Person Enrichment」のプロンプトでディスパッチします。各サブエージェントのプロンプトには以下を含める必要があります：

• {SKILL_DIR}、{OUTPUT_DIR}、{DEPTH}（deep | deeper）
• {USER_COMPANY}、{USER_PRODUCT}、{ICP_DESCRIPTION}
• {EVENT_NAME}（recon.json の .title から）
• {LANES} → deep モードでは 2、deeper モードでは 4（# browse call N/{LANES} に代入されます）
• {PEOPLE_BATCH} → _batch_people_aa の内容（各行は people.jsonl の JSON レコード）

Agent ディスパッチ（スケルトン、1 つのメッセージ内でバッチごとに繰り返す）：

Agent(
  description: "Person enrichment batch aa",
  prompt: <Person Enrichment prompt from workflow.md with all placeholders substituted; PEOPLE_BATCH = cat _batch_people_aa>,
  subagent_type: "general-purpose"
)
Agent(
  description: "Person enrichment batch ab",
  prompt: <same template, PEOPLE_BATCH = cat _batch_people_ab>,
  subagent_type: "general-purpose"
)
... up to 6 per message

すべてのサブエージェントが戻ったら、people ファイルが存在することを確認します：

ls {OUTPUT_DIR}/people/*.md | wc -l
# Should equal wc -l _people_to_enrich.jsonl

ステップ 9：レポートのコンパイル

企業ごとにグループ化された HTML インデックス、代替ビュー、CSV を 1 つのコマンドで生成します：

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 人の人物カードを markdown テーブルとして表示し、次に以下を提案します：

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