다음 주 컨퍼런스 전에 발표자 400명을 선별해야 할 때, 모든 사람을 ICP 적합도 기준으로 점수화해 우선순위 목록을 들고 현장에 도착하세요. — Claude Skill

이벤트 잠재고객 발굴

컨퍼런스 URL을 넣으면 영업 담당자가 이야기해야 할 사람의 순위 목록과, 각 사람별 "왜 연락해야 하는가" 근거를 얻습니다.

필수: BROWSERBASE_API_KEY 환경 변수와 설치된 browse CLI(npm install -g browse). API 호출에는 browse cloud ...를 사용하고, JS가 많은 발표자 페이지에는 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를 함께 만듭니다.

중요 — 도구 제한(메인 에이전트와 모든 서브에이전트에 적용):

• 모든 웹 검색: browse cloud search를 사용합니다. WebSearch는 절대 사용하지 않습니다.
• 모든 페이지 콘텐츠 추출: node {SKILL_DIR}/scripts/extract_page.mjs "<url>"를 사용합니다. 이 스크립트는 browse cloud fetch --output으로 가져온 뒤 title + meta tags + visible body text를 파싱하고, fetch가 실패하거나 JS 렌더링 콘텐츠가 너무 얇을 때 browse get markdown으로 자동 대체 처리합니다. browse cloud fetch | sed 처리 흐름을 직접 만들지 않습니다. WebFetch는 절대 사용하지 않습니다.
• 모든 조사 출력: 서브에이전트는 Bash heredoc으로 {OUTPUT_DIR}/companies/{slug}.md 또는 {OUTPUT_DIR}/people/{slug}.md에 회사당 또는 사람당 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가 타깃 설명에 스며들게 하지 않습니다. 타깃이 무엇을 하는지 모르면 Unknown이라고 씁니다. ICP에 맞춰 억지로 패턴 매칭하지 않습니다.
• 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개월의 공개 신호가 없으면 이벤트 맥락(이번 행사 발표 제목)으로 대체합니다.

중요 — 승인 프롬프트 최소화:

• 서브에이전트는 모든 파일 쓰기를 chained heredoc을 사용하는 단일 Bash 호출 하나로 묶어야 합니다. Bash 호출 1회 = 승인 프롬프트 1회입니다.
• 모든 검색과 모든 fetch를 && chaining으로 단일 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 확인을 요청하지 않습니다. 사용자가 이미 제공했습니다.

---

Step 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}를 전체 리터럴 경로로 전달합니다.

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을 나열합니다. 프로필이 정확히 하나면 그것을 사용하고 어떤 프로필을 쓰는지 사용자에게 알립니다. 여러 개면 사용자에게 일반 채팅으로 어느 것을 쓸지 묻습니다.
3. 프로필이 하나도 없으면 명확히 실패하고 사용자에게 만들라고 안내합니다. 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 "프로필을 찾을 수 없습니다: {SKILL_DIR}/profiles/. profiles/example.json을 profiles/<your_slug>.json으로 복사해 채우거나, company-research 스킬을 실행해 자동 생성하세요."
    exit 1
  elif [ "$COUNT" -eq 1 ]; then
    USER_SLUG=$PROFILES
    echo "사용 가능한 유일한 프로필을 사용합니다: ${USER_SLUG}"
  else
    echo "여러 프로필을 찾았습니다:"
    echo "$PROFILES" | sed 's/^/  - /'
    echo "하나를 고르려면 --user-company <slug>로 다시 호출하세요."
    exit 1
  fi
fi

test -f {SKILL_DIR}/profiles/${USER_SLUG}.json || {
  echo "프로필을 찾을 수 없습니다: profiles/${USER_SLUG}.json"
  exit 1
}
cat {SKILL_DIR}/profiles/${USER_SLUG}.json

프로필은 company, product, icp_description, existing_customers를 제공합니다. 이 값들은 이후 모든 서브에이전트 프롬프트에 그대로 포함합니다.

Step 2: 사전 확인

이벤트 플랫폼과 추출 전략을 감지합니다. 명령 하나만 실행합니다.

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개 path
• 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(한 줄에 발표자 한 명)과 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를 출력합니다(한 줄에 회사 하나, 중복 제거, 정렬). 이 단계는 정보 확인용입니다. 병렬 분배 전에 개수가 타당한지 확인합니다.

wc -l {OUTPUT_DIR}/seed_companies.txt

예상: 발표자 수의 약 0.4-0.6배입니다. 대부분 행사는 회사당 평균 발표자 2명 정도이며, 어떤 회사는 5명 이상을 보내고 많은 회사는 1명만 보냅니다.

Step 5: ICP 선별

빠른 패스 — 회사당 도구 호출 1회, 심층 조사 없음. seed_companies.txt의 모든 회사를 사용자의 ICP와 비교해 점수화하고 얇은 선별 초안을 companies/{slug}.md에 씁니다. icp_fit_score >= --icp-threshold(기본값 6)인 회사는 Step 7의 심층 조사로 넘어가고, 나머지는 선별 초안으로 남습니다.

호출 패턴: seed_companies.txt를 약 10개 회사씩 배치로 나누고, 단일 Agent 배치에서 N개 서브에이전트로 병렬 분배합니다(한 메시지에 여러 Agent 도구 호출). 각 서브에이전트는 references/workflow.md → "ICP Triage" 섹션의 프롬프트를 실행합니다. 엄격한 한도: 회사당 도구 호출 1회(extract_page.mjs로 홈페이지만), # browse call N/1 주석 패턴으로 집행합니다.

# 배치 파일을 만듭니다. 각 줄은 "name|guessed_homepage|slug"입니다.
# extract_event.mjs는 회사 이름만 출력하므로(URL 없음), slug를 만들고
# https://{slug-without-spaces}.com 을 표준 홈페이지로 추정합니다. triage 서브에이전트는
# 추정 URL이 404이면 product_description: "Unknown — homepage content not accessible"라고 쓰고
# score를 3으로 제한할 수 있습니다. 이것은 workflow.md에 문서화된 대체 처리입니다
# (ICP Triage 프롬프트의 규칙 3). URL을 찾기 위해 실제 browse cloud search를 쓰면
# 회사당 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개, 나머지는 두 번째 묶음)
ls {OUTPUT_DIR}/_batch_triage_* | wc -l

그다음 한 메시지에서 배치당 Agent 호출 하나를 전송합니다(최대 6개 병렬, 첫 묶음이 돌아오면 다음 묶음). 전송 전에 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 호출(골격, 한 메시지 안에서 배치마다 반복):

Agent(
  description: "ICP 선별 배치 aa",
  prompt: <모든 placeholder를 치환한 workflow.md의 ICP Triage 프롬프트>,
  subagent_type: "general-purpose"
)
Agent(
  description: "ICP 선별 배치 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_*.

Step 6: ICP threshold로 필터링

각 companies/*.md의 앞부분 메타데이터를 읽고 icp_fit_score >= 6(또는 --icp-threshold 값)인 항목만 유지합니다. 살아남은 회사 slug를 {OUTPUT_DIR}/icp_fits.txt에 씁니다.

THRESHOLD=6   # --icp-threshold 플래그에서 온 값
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% 미만이면 threshold가 너무 높거나 ICP 설명이 너무 좁을 수 있습니다. 사용자에게 경고를 보여 줍니다.

Step 7: 심층 조사

ICP 적합 회사만 대상으로 Plan→Research→Synthesize 전체를 실행합니다. 엄격한 한도: 회사당 도구 호출 5회(홈페이지 추출 + 하위 질문 검색 2-3회 + 보조 fetch 1-2회). 서브에이전트는 기존 companies/{slug}.md 선별 초안을 더 풍부한 심층 조사 버전으로 덮어씁니다(앞부분 메타데이터 triage_only: false).

호출 패턴: icp_fits.txt를 약 5개 회사씩 배치로 나누고(기본 deep 모드), 단일 메시지에서 배치당 Agent 하나로 병렬 분배합니다(한 메시지에 최대 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}(이벤트 홈페이지에서 수동 추론한 track / topic)
• {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개 회사씩 나눕니다(deep 모드)
split -l 5 {OUTPUT_DIR}/_deep_targets.txt {OUTPUT_DIR}/_batch_deep_
ls {OUTPUT_DIR}/_batch_deep_* | wc -l

Agent 호출(골격, 한 메시지 안에서 배치마다 반복):

Agent(
  description: "심층 조사 배치 aa",
  prompt: <모든 placeholder를 치환한 workflow.md의 Deep Research 프롬프트; COMPANY_LIST = cat _batch_deep_aa>,
  subagent_type: "general-purpose"
)
Agent(
  description: "심층 조사 배치 ab",
  prompt: <같은 템플릿, COMPANY_LIST = cat _batch_deep_ab>,
  subagent_type: "general-purpose"
)
... 한 메시지에 최대 6개, 첫 묶음 후 두 번째 묶음

모든 서브에이전트가 돌아오면 심층 조사 파일이 존재하고 triage_only: false가 있는지 확인합니다.

grep -l "triage_only: false" {OUTPUT_DIR}/companies/*.md | wc -l
# wc -l icp_fits.txt와 같아야 합니다

Step 8: 발표자 보강

사람별로 LinkedIn URL과 최근 활동(팟캐스트 / 블로그 / 발표 / GitHub / X)을 수집하고 people/{slug}.md를 씁니다. 엄격한 한도: 사람당 도구 호출 4회, 세 갈래로 진행합니다.

1. browse cloud search "{name} {company} linkedin"(항상)
2. browse cloud search "{name} podcast OR talk OR blog 2026"(deep 이상)
3. browse cloud search "{name} github"(deeper)
4. browse cloud search "{name} site:x.com OR site:twitter.com"(deeper, 최선의 시도)

quick 모드에서는 Step 8을 완전히 건너뜁니다. deep 모드에서는 1-2번 갈래를 수행합니다. deeper 모드에서는 1-4번 갈래를 수행합니다.

Step 8a — 사용자에게 질문: 보강 범위

호출 전에 두 후보 개수를 계산하고 사용자에게 선택하게 합니다. 기본값은 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);
')

# 사람당 갈래 수: 2(deep) 또는 4(deeper) — {DEPTH}와 맞춥니다
LANES=2   # deeper이면 4
echo "ICP 적합: ${ICP_FITS}명 × ${LANES} = $((ICP_FITS * LANES))회 호출"
echo "전체:      ${TOTAL}명 × ${LANES} = $((TOTAL * LANES))회 호출"

그다음 AskUserQuestion으로 묻습니다. 각 선택지에 정량화된 비용이 있는 깔끔한 두 가지 선택입니다.

AskUserQuestion(questions: [
  {
    question: "어떤 발표자를 보강할까요?",
    header: "보강 범위",
    multiSelect: false,
    options: [
      { label: "ICP 적합만", description: "${ICP_FITS}명, 약 $((ICP_FITS * LANES))회 호출(권장)" },
      { label: "모든 발표자", description: "${TOTAL}명, 약 $((TOTAL * LANES))회 호출" }
    ]
  }
])

선택한 범위를 ENRICH_SCOPE=icp_fits 또는 ENRICH_SCOPE=all로 저장합니다. 사용자가 "모든 발표자"를 선택했고 TOTAL × LANES > 600이면 경고를 출력하고 한 번 더 묻습니다. 이는 수백 번의 도구 호출이 필요한 10분 이상 실행입니다.

Step 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_

그다음 한 메시지에서 배치당 Agent 호출 하나를 전송합니다(한 메시지에 최대 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 record가 한 줄에 하나씩)

Agent 호출(골격, 한 메시지 안에서 배치마다 반복):

Agent(
  description: "개인 보강 배치 aa",
  prompt: <모든 placeholder를 치환한 workflow.md의 Person Enrichment 프롬프트; PEOPLE_BATCH = cat _batch_people_aa>,
  subagent_type: "general-purpose"
)
Agent(
  description: "개인 보강 배치 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과 같아야 합니다

Step 9: 보고서 컴파일

회사별로 그룹화된 HTML index, 대체 보기, 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 Name}

- **추출된 발표자 총수**: {count}
- **고유 회사**: {count}
- **ICP 적합(점수 ≥ {threshold})**: {count}
- **보강된 발표자**: {count}
- **점수 분포**(회사):
  - 강한 적합(8-10): {count}
  - 부분 적합(5-7): {count}
  - 약한 적합(1-4): {count}
- **브라우저에서 열린 보고서**: {OUTPUT_DIR}/index.html

회사 ICP 점수 기준으로 정렬한 상위 5개 사람 카드를 markdown 표로 보여 준 뒤 다음을 제안합니다.

• --icp-threshold를 조정하고 Steps 6-9를 다시 실행
• CSV를 CRM으로 내보내기