몇 분 안에 점수화된 잠재고객 리스트를 만듭니다. 50개 계정을 넣으면 리서치와 CSV가 돌아옵니다. — Claude Skill

기업 리서치 파일 예시

각 research subagent는 {OUTPUT_DIR}/{company-slug}.md에 회사별 markdown 파일 하나를 씁니다. 여기서 {OUTPUT_DIR}는 main agent가 Step 0에서 만든 per-run Desktop directory입니다(예: ~/Desktop/acme_research_2026-04-23/). YAML frontmatter에는 report + CSV compilation용 structured field가 들어 있습니다. Body에는 사람이 읽을 수 있는 리서치가 들어 있습니다.

템플릿

---
company_name: Acme Inc
website: https://acme.com
product_description: AI-powered inventory management for e-commerce brands
industry: E-commerce / SaaS
target_audience: Mid-market e-commerce brands
key_features: demand forecasting | automated reordering | multi-warehouse sync
icp_fit_score: 8
icp_fit_reasoning: Series A e-commerce SaaS, uses Selenium for scraping, expanding to EU — strong fit
employee_estimate: 50-100
funding_info: Series A, $12M
headquarters: San Francisco, CA
---

## Product
AI-powered inventory management for e-commerce brands. Helps DTC brands
automate reordering and sync across multiple warehouses.

## Research Findings
- **[high]** Checkout optimization for Shopify stores, serving mid-market DTC brands with $5M-$50M revenue (source: acme.com/about)
- **[high]** Series A, $12M raised in Q3 2025 from Sequoia (source: TechCrunch)
- **[medium]** Recently hired 3 data engineers, expanding platform team (source: LinkedIn job posts)
- **[medium]** Uses Selenium for web scraping in their data pipeline (source: careers page)

필드 규칙

• YAML frontmatter: 모든 structured field는 여기에 둡니다. CSV compilation 때 추출됩니다.
• key_features: YAML에서는 JSON array가 아니라 pipe-separated(|) list입니다.
• icp_fit_score: 정수 1-10.
• icp_fit_reasoning: 한 줄이며 specific finding을 참조합니다.
• Body sections: ## Product, ## Research Findings.
• Findings format: - **[confidence]** fact (source: url or description)
• Filename: {OUTPUT_DIR}/{company-slug}.md, slug는 lowercase, hyphenated입니다(예: acme-inc.md).
• Deduplication: 회사별 파일 하나. subagent가 이미 파일이 있는 회사를 만나면 더 풍부한 data로 overwrite합니다.

Bash Heredoc으로 쓰기

Subagent는 security prompt를 피하기 위해 bash heredoc으로 파일을 씁니다. 전체 literal {OUTPUT_DIR} path를 사용하세요. ~나 $HOME은 사용하지 않습니다.

cat << 'COMPANY_MD' > {OUTPUT_DIR}/acme-inc.md
---
company_name: Acme Inc
website: https://acme.com
...
---

## Product
...

## Research Findings
...
COMPANY_MD

Shell variable expansion을 막기 위해 delimiter는 'COMPANY_MD'(quoted)를 사용합니다.

중요: permission prompt를 최소화하려면 모든 company file을 chained heredoc을 사용한 단일 Bash call에서 씁니다.

기업 리서치 — Deep Research Patterns

개요

이 reference는 두 가지 리서치 context를 정의합니다.

1. Self-Research(Step 1) — 강한 ICP 기반을 만들기 위한 사용자 회사 자체에 대한 deep research
2. Target Research(Step 6) — 발견된 각 회사를 Plan→Research→Synthesize로 리서치

둘 다 같은 3-phase pattern을 사용하지만 sub-question과 목표가 다릅니다.

Self-Research(사용자 회사)

Pipeline에서 가장 중요한 리서치입니다. downstream의 모든 결정이 여기에 달려 있습니다.

Sub-Questions

• "{company}는 무엇을 팔고 어떤 specific problem을 해결하는가?"
• "{company}의 기존 customer는 누구인가? 어떤 industry, company size, use case인가?"
• "{company}의 competitor는 누구이며 무엇이 차별점인가?"
• "{company}는 어떤 pricing model을 사용하고 typical buyer persona는 누구인가?"
• "{company}의 marketing은 어떤 use case와 pain point를 강조하는가?"

Page Discovery

Site page를 동적으로 발견합니다. /about 또는 /customers 같은 path를 hardcode하지 마세요.

1. browse cloud fetch --allow-redirects "{company website}/sitemap.xml" fetch — primary source이며 모든 page가 있습니다.
2. Sitemap URL에서 키워드를 scan합니다: customer, case-stud, pricing, about, use-case, blog, docs, industry, solution
3. 선택적으로 page description용 browse cloud fetch --allow-redirects "{company website}/llms.txt"를 fetch합니다.
4. Sitemap에서 가장 관련 있는 URL 3-5개를 고르고 fetch합니다.
5. Sitemap이 source of truth입니다. llms.txt는 bonus context지만 종종 불완전합니다.

External Research

• Search: "{company} customers use cases reviews"
• Search: "{company} alternatives competitors vs"
• 가장 정보가 많은 third-party result 1-2개를 fetch합니다(G2, blog post, comparison).

Synthesis Output

모든 findings에서 company profile을 만듭니다.

• Company: 이름
• Product: 무엇을 팔고, 어떻게 작동하며, 핵심 capability는 무엇인지(구체적인 2-3문장)
• Existing Customers: 발견된 named customer 또는 customer type
• Competitors: 경쟁 대상과 key differentiator
• Use Cases: 제품이 제공하는 broad use case list(한 vertical에 묶지 않음)

Profile에는 ICP, pitch angle, sub-vertical을 포함하지 않습니다. 이것들은 profile 확인 후 Step 2에서 정하는 per-run targeting decision입니다. Profile은 다음에 어떤 vertical을 target하더라도 사용할 수 있는 범용 company fact sheet입니다.

왜 중요한가

얇은 profile은 generic search query, 약한 lead scoring, cookie-cutter email을 만듭니다. Specific customer, competitor, use case가 있는 rich profile은 targeted query, 정확한 scoring, 실제 pain point를 언급하는 email을 만듭니다.

타깃 기업 리서치(Step 6)

Sub-Question Templates

ICP와 요청된 enrichment field를 기준으로 아래 범주에서 sub-question을 생성합니다. 모든 범주가 모든 회사에 적용되는 것은 아닙니다. 가장 관련 있는 것을 고릅니다.

Priority 1(항상 질문)

• Product/Market: "{company}는 무엇을 팔고 고객은 누구인가?"
• ICP Fit: "{company}의 product/market은 {sender's ICP description}과 어떻게 관련되는가?"

Priority 2(deep/deeper에서 질문)

• Tech Stack: "{company}는 어떤 technology, framework, infrastructure를 사용하는가?"
• Growth Signals: "{company}가 최근 투자 유치, 제품 출시, 확장을 했는가?"
• Pain Points: "{company}가 {sender's product}가 해결하는 어떤 challenge를 겪을 수 있는가?"

Priority 3(deeper에서만 질문)

• Decision Makers: "{company}에서 engineering, product, growth를 누가 이끄는가?"
• Competitive Landscape: "{company}의 competitor는 누구이고 어떻게 차별화되는가?"
• Customers/Case Studies: "{company}의 notable customer는 누구이고 어떤 성과를 강조하는가?"

Search Query Patterns

각 sub-question마다 search query variation 2-3개를 생성합니다.

# Product/Market
"{company name} what they do"
"{company name} product features customers"

# Tech Stack
"{company name} tech stack engineering blog"
"{company name} careers software engineer" (job post는 stack을 드러냅니다)

# Growth Signals
"{company name} funding round 2025 2026"
"{company name} launch announcement"
"{company name} hiring"

# Pain Points
"{company name} challenges {relevant domain}"
"{company name} {problem sender solves}"

# Decision Makers
"{company name} VP engineering CTO LinkedIn"
"{company name} head of growth product"

Finding Format

각 finding은 source에 연결된 self-contained factual statement입니다.

{
  "subQuestion": "What does Acme sell and who are their customers?",
  "fact": "Acme provides checkout optimization for Shopify stores, serving mid-market DTC brands with $5M-$50M revenue",
  "sourceUrl": "https://acme.com/about",
  "sourceTitle": "About Acme - Checkout Optimization",
  "confidence": "high"
}

Confidence levels:

• high: 회사의 own website 또는 official press에 직접 명시됨
• medium: job posting, third-party article, indirect signal에서 추론됨
• low: industry/category 기반 추측이거나 오래된 source

리서치 루프 규칙

1. Priority 순서대로 sub-question 처리 — Priority 1 먼저, 그다음 2, 그다음 3
2. Sub-question당 finding 3-5개를 모은 뒤 이동 — 한 topic을 과도하게 파지 않습니다.
3. Parallel tool call 사용 — 가능하면 여러 query를 동시에 search합니다.
4. Retry보다 rephrase — search result가 좋지 않으면 다른 keyword를 시도합니다.
5. 선별적으로 fetch — search result의 모든 URL을 fetch하지 않습니다. title과 URL 기준으로 가장 관련 있는 1-2개를 고릅니다.
6. Step limit에서 중지 — depth mode의 회사별 step budget을 지킵니다.
7. Homepage first — 다른 page로 branching하기 전에 항상 company homepage를 fetch합니다.
8. Finding deduplicate — 같은 fact를 다른 source에서 두 번 기록하지 않습니다.

깊이 모드 동작

Quick Mode(lead 100개 이상)

• Phase A skip — sub-question decomposition 없음
• Phase B: company homepage를 fetch합니다. homepage data가 얇으면 보조 search 1-2개를 실행합니다.
• Phase C: 가능한 data를 extract하고 ICP를 점수화하며, 가능한 내용으로 email을 씁니다.
• Budget: 회사당 총 tool call 2-3회
• Trade-off: 빠르고 저렴하지만 이메일 개인화가 약할 수 있습니다.

Deep Mode(lead 25-50개)

• Phase A: 하위 질문 2-3개로 분해합니다(Priority 1 + 선택된 Priority 2).
• Phase B: 각 sub-question마다 search 2-3개 + URL fetch 1-2개. Sub-question당 finding 3-5개를 목표로 합니다.
• Phase C: 모든 finding에서 종합합니다. ICP reasoning은 specific evidence를 참조합니다. Email은 가장 구체적이고 설득력 있는 finding을 사용합니다.
• Budget: 회사당 총 tool call 5-8회
• Trade-off: 깊이와 규모의 좋은 균형

Deeper Mode(lead 10-25개)

• Phase A: 하위 질문 4-5개로 분해합니다(Priority 1 + 2 + 선택된 Priority 3).
• Phase B: exhaustive research를 수행합니다. 회사별로 여러 page(homepage, about, blog, careers, product pages)를 fetch합니다. Sub-question당 finding 3-5개를 목표로 합니다.
• Phase C: cited evidence로 종합합니다. ICP reasoning은 상세합니다. Email은 여러 specific signal을 참조합니다.
• Budget: 회사당 총 tool call 10-15회
• Trade-off: 고품질 intelligence이지만 느리고 비쌉니다.

종합 지침

회사에 대한 research loop가 끝나면 findings를 output record로 종합합니다.

ICP Scoring

축적한 모든 findings를 evidence로 사용해 1-10점으로 점수화합니다.

• 8-10: Strong match. 여러 high-confidence finding이 올바른 industry, company stage, 명확한 pain point alignment를 확인합니다. Pitch angle이 evidence로 뒷받침되는 visible need를 직접 다룹니다.
• 5-7: Partial match. 일부 finding은 relevance를 시사하지만 key signal이 없거나 low-confidence입니다. Adjacent industry 또는 불명확한 pain point.
• 1-4: Weak match. Findings가 잘못된 segment, 너무 크거나 작은 규모, sender product와의 연결 없음 등을 나타냅니다.

icp_fit_reasoning은 specific finding을 참조해 작성합니다: "Series A fintech (from Crunchbase), uses Selenium for scraping (from job posting), expanding to EU market (from blog) — strong fit for browser infrastructure."

이메일 개인화

Email context에는 가장 풍부하고 구체적인 findings를 사용합니다.

• Opening: 가장 구체적인 finding 사용(특정 product feature, 최근 launch, job posting)
• Bridge: challenge/stack에 대한 finding을 sender의 pitch angle과 연결
• low-confidence finding만 있으면 email을 더 짧고 일반적으로 유지합니다. 구체성을 지어내지 마세요.

Enrichment Fields

Findings를 enrichment field에 매핑합니다.

• product_description → Product/Market findings에서
• industry → Product/Market에서 추론
• employee_estimate → LinkedIn search 또는 careers page findings에서
• funding_info → Growth Signals findings에서
• headquarters → company homepage 또는 about page에서
• target_audience → Product/Market findings에서
• key_features → product page findings에서

지원하는 finding이 없는 field는 추측하지 말고 비워둡니다.

Anti-Hallucination Rules

Synthesis 시점에 다음을 적용합니다. 특히 server-rendered copy가 거의 없는 Framer/Next.js landing page에서 subagent가 visual cue를 sender ICP에 pattern-match해 그럴듯한 설명을 지어내는 failure mode를 막기 위한 규칙입니다.

1. Typography는 제품이 아닙니다. Font, design system, framework choice(Framer, Next.js, React), site polish만 보고 product_description, industry, target_audience를 추론하지 않습니다. "Framer-built"와 "uses Geist Mono"는 tooling에 대한 관찰이지 회사가 무엇을 파는지에 대한 signal이 아닙니다.
2. ICP leakage 금지. Homepage가 얇고 external search에서도 아무것도 나오지 않으면 target description을 sender ICP 쪽으로 기본값 처리하지 않습니다. 둘 다 AI를 쓴다는 이유만으로 manufacturing AI가 browser automation인 것은 아닙니다.
3. 기억에서 paraphrase하지 말고 quote하세요. product_description은 extract_page.mjs output(TITLE / META_DESCRIPTION / OG_DESCRIPTION / HEADINGS / BODY) 또는 external search result의 specific phrase를 quote하거나 가까이 paraphrase해야 합니다. 그런 phrase가 없으면 Unknown — homepage content not accessible라고 씁니다.
4. 얇은 evidence에서는 score cap 적용. product_description이 Unknown이면 icp_fit_score ≤ 3으로 설정하고 icp_fit_reasoning: Insufficient evidence — homepage returned no readable content를 사용합니다. 추론 신호만으로 더 높은 score를 정당화하지 않습니다.

기업 리서치 — Workflow 참고 자료

Discovery Batch JSON 스키마

파일: /tmp/company_discovery_batch_{N}.json

browse cloud search --output은 flat array가 아니라 JSON object를 씁니다.

{
  "requestId": "abc123",
  "query": "AI data extraction startups",
  "results": [
    { "url": "https://example.com", "title": "Example Corp", "author": null, "publishedDate": null },
    ...
  ]
}

list_urls.mjs script는 두 형식(flat array와 { results: [...] })을 모두 처리합니다.

기업 리서치 Markdown 형식

파일: {OUTPUT_DIR}/{company-slug}.md

여기서 {OUTPUT_DIR}는 사용자의 Desktop에 있는 per-run directory입니다(예: ~/Desktop/acme_research_2026-04-23/). Main agent가 Step 0에서 이를 만들고 모든 subagent에 전체 literal path를 전달합니다.

각 research subagent는 회사별 markdown file 하나를 씁니다. 전체 템플릿은 references/example-research.md를 참고하세요.

YAML frontmatter fields(report + CSV compilation에 사용):

• company_name(required)
• website(required)
• product_description
• industry
• target_audience
• key_features(pipe-separated: feature1 | feature2 | feature3)
• icp_fit_score(정수 1-10, required)
• icp_fit_reasoning
• employee_estimate
• funding_info
• headquarters

Body sections:

• ## Product — 무엇을 하는지
• ## Research Findings — confidence level과 source가 있는 증거

중요: 모든 파일에서 field name을 일관되게 사용합니다. compile_report.mjs script가 이 field들을 읽습니다.

Page Content 추출

모든 homepage/product-page content extraction에는 extract_page.mjs를 사용합니다. 이 script는 browse cloud fetch --output으로 fetch하고 title + meta + visible body text를 parse하며, fetch가 실패하거나 얇은 JS-rendered content를 반환하면 자동으로 browse get markdown으로 fallback합니다.

node {SKILL_DIR}/scripts/extract_page.mjs "https://example.com" --max-chars 3000

출력은 structured block입니다.

URL: https://example.com
FETCH_OK: true|false
FALLBACK_TO_BROWSE: true|false
TITLE: ...
META_DESCRIPTION: ...
OG_TITLE: ...
OG_DESCRIPTION: ...
HEADINGS: h1/h2/h3 joined by " | "
BODY_CHARS: N
BODY:
<cleaned visible text, max N chars>

raw browse cloud fetch | sed pipeline을 쓰지 않는 이유는? --output이 없으면 browse cloud fetch는 HTML이 escaped string으로 들어간 JSON envelope를 반환합니다. 단순 sed pipeline은 wrapper와 content에서 <>를 제거하고 <meta> tag를 없앱니다. Framer/Next.js SPA에서는 meta tag가 유일하게 읽을 수 있는 content인 경우가 많습니다. extract_page.mjs는 --output으로 raw HTML을 직접 parse합니다.

raw browse cloud fetch 사용 시점: JSON envelope를 그대로 보려는 작은 structured file에만 사용합니다. 예: sitemap.xml, robots.txt, llms.txt. 모델에 넣을 HTML page에는 extract_page.mjs를 사용합니다.

Content가 실제인지 검증하기(환각 방지)

회사 파일에 product_description, industry, target_audience를 쓰기 전에 claim이 extract_page.mjs output에 근거하는지 확인합니다. TITLE, META_DESCRIPTION, OG_DESCRIPTION, HEADINGS 또는 BODY에서 quote하거나 가까이 paraphrase합니다.

extract_page.mjs가 FETCH_OK: false와 FALLBACK_TO_BROWSE: false를 반환하거나 BODY_CHARS < 50이면 homepage 접근이 불가능합니다. 지어내지 마세요. 다음처럼 씁니다.

• product_description: Unknown — homepage content not accessible
• icp_fit_score: 3(또는 더 낮게)
• icp_fit_reasoning: Insufficient evidence — homepage returned no readable content

이 규칙이 막는 전형적 실패 모드: server-rendered copy가 없는 Framer/Next.js landing page에서 subagent가 visual cue("design-forward", "Geist Mono", "Framer-built")를 사용자의 ICP에 맞춰 해석하는 경우. Typography는 제품이 아닙니다.

Discovery Subagent Prompt Template

당신은 company discovery subagent입니다. Search query를 실행하고 결과를 저장하세요.

도구 규칙 — 중요, 정확히 따르세요:
1. Bash tool만 사용할 수 있습니다. 예외는 없습니다.
2. 모든 search를 && chaining을 사용한 단일 Bash call에서 실행합니다.
3. 금지 도구: WebFetch, WebSearch, Write, Read, Glob, Grep — 모두 금지입니다.
   금지된 tool을 하나라도 사용하면 전체 run이 실패합니다. Bash만 사용하세요.
4. path에는 ~ 또는 $HOME을 절대 사용하지 말고 full literal path를 사용하세요.

TASK:
다음 모든 search를 하나의 Bash command에서 실행하세요.

browse cloud search "{query1}" --num-results 25 --output /tmp/company_discovery_batch_{N1}.json && \
browse cloud search "{query2}" --num-results 25 --output /tmp/company_discovery_batch_{N2}.json && \
browse cloud search "{query3}" --num-results 25 --output /tmp/company_discovery_batch_{N3}.json && \
echo "Discovery complete"

Command 완료 후 batch별 발견된 result count만 보고하세요.
실제 result를 분석, 요약 또는 반환하지 마세요.

리서치 Subagent Prompt 템플릿

당신은 company research subagent입니다. 각 company URL을 리서치하고 ICP fit을 점수화하세요.

CONTEXT:
- User's company: {user_company}
- User's product: {user_product}
- ICP description: {icp_description}
- Depth mode: {depth_mode}
- 출력 디렉터리: {OUTPUT_DIR}   ← research file을 여기에 쓰세요. full literal path입니다.

URLS TO PROCESS:
{url_list}

도구 규칙 — 중요, 정확히 따르세요:
1. Bash tool만 사용할 수 있습니다. 예외는 없습니다.
2. 모든 search: Bash → browse cloud search "..." --num-results 10
3. 모든 homepage/product-page content extraction:
   Bash → node {SKILL_DIR}/scripts/extract_page.mjs "URL" --max-chars 3000
   이 명령은 structured TITLE / META_DESCRIPTION / OG_DESCRIPTION / HEADINGS / BODY를 반환하고, fetch가 실패하거나 얇은 JS-rendered content를 반환하면 browse get markdown으로 자동 fallback합니다.
   `browse cloud fetch | sed` pipeline을 직접 만들지 마세요. meta tag를 제거하고 stdout JSON envelope를 parse하지 못합니다. sitemap.xml, robots.txt, llms.txt에만 raw `browse cloud fetch`를 사용하세요.
4. 모든 file write를 batch 처리하세요. Chained heredoc을 사용한 단일 Bash call에서 모든 markdown file을 씁니다(permission prompt 하나, 파일별 prompt 아님).
5. 금지 도구: WebFetch, WebSearch, Write, Read, Glob, Grep — 모두 금지입니다.
   금지된 tool을 하나라도 사용하면 전체 run이 실패합니다. Bash만 사용하세요.
6. path에는 ~ 또는 $HOME을 절대 사용하지 말고 full literal path를 사용하세요.

환각 방지 규칙 — 중요:
- font, framework(Framer/Next.js/React), design system, visual style만 보고 product_description, industry, target_audience를 절대 추론하지 않습니다. Typography는 제품이 아닙니다.
- sender의 ICP가 target description에 새어 들어가게 하지 않습니다. 타깃이 무엇을 하는지 모르면 "Unknown"이라고 쓰세요. ICP에 맞춰 pattern-match하지 마세요.
- product_description은 extract_page.mjs output의 문구를 quote하거나 가까이 paraphrase해야 합니다. TITLE/META/OG/HEADINGS/BODY 어느 곳에서도 알아볼 수 있는 product statement가 없으면 "Unknown — homepage content not accessible"라고 쓰고 icp_fit_score를 최대 3으로 제한하세요.

RESEARCH PATTERN(회사별):

Phase A — Plan(quick mode에서는 skip):
ICP와 enrichment field를 기준으로 알아야 할 것을 하위 질문으로 분해합니다.

Phase B — Research Loop:
각 하위 질문(또는 quick mode에서는 homepage만)에 대해:
1. 관련 query로 browse cloud search를 실행합니다.
2. Result에서 가장 관련 있는 URL 1-2개를 고릅니다.
3. Page content를 extract합니다: node {SKILL_DIR}/scripts/extract_page.mjs "URL" --max-chars 3000
   (`--output`을 사용해 stdout JSON envelope를 피하고, meta tag를 보존하며, 필요 시 browse get markdown으로 fallback합니다.)
4. Smart page discovery: /sitemap.xml 또는 /llms.txt에 `browse cloud fetch --allow-redirects`를 사용해 관련 URL을 찾습니다. 이것들은 작은 XML/text file이라 raw JSON envelope가 괜찮습니다. 발견한 실제 HTML page에는 extract_page.mjs를 사용합니다.
5. Findings를 추출합니다: source와 confidence level이 있는 factual statement.
6. Findings를 축적하고 다음 하위 질문으로 넘어갑니다.
7. Step budget을 지킵니다: quick=2-3 calls, deep=5-8, deeper=10-15.

Phase C — Synthesize:
축적한 findings에서:
1. ICP fit을 1-10점으로 매깁니다(아래 rubric 참고).
2. Findings로 enrichment field를 채웁니다.
3. icp_fit_reasoning에서 specific finding을 참조합니다.

ICP SCORING RUBRIC:
- 8-10: Strong match. 여러 high-confidence finding이 fit을 확인합니다.
- 5-7: Partial match. 일부 finding은 relevance를 시사하지만 key signal이 부족합니다.
- 1-4: Weak match. 잘못된 segment이거나 명확한 연결이 없습니다.

OUTPUT — chained heredoc을 사용한 단일 Bash call로 모든 company file을 {OUTPUT_DIR}에 직접 씁니다.

cat << 'COMPANY_MD' > {OUTPUT_DIR}/{slug1}.md
---
company_name: {name}
website: {url}
product_description: {description}
industry: {industry}
target_audience: {audience}
key_features: {feature1} | {feature2} | {feature3}
icp_fit_score: {score}
icp_fit_reasoning: {reasoning}
employee_estimate: {estimate}
funding_info: {funding}
headquarters: {location}
---

## Product
{product description paragraph}

## Research Findings
- **[{confidence}]** {finding} (source: {url})
COMPANY_MD
cat << 'COMPANY_MD' > {OUTPUT_DIR}/{slug2}.md
---
...
---
...
COMPANY_MD

Shell variable expansion을 막기 위해 heredoc delimiter는 'COMPANY_MD'(quoted)를 사용합니다.

다음만 보고하세요: "Batch {batch_id}: {succeeded}/{total} researched, {findings_count} total findings."
Raw data를 main conversation에 반환하지 마세요.

Wave Management

핵심 원칙: Parallelism 극대화, Prompt 최소화

한 메시지에서 가능한 한 많은 subagent를 launch합니다(메시지당 Agent tool call 약 6개까지). 각 subagent는 permission prompt를 최소화하기 위해 모든 Bash operation을 batch 처리해야 합니다.

Discovery Phase

• 한 메시지에서 discovery subagent를 최대 6개 launch합니다.
• 각 subagent는 && chaining을 사용한 단일 Bash call에서 모든 query를 실행합니다.
• 모든 wave 완료 후 node {SKILL_DIR}/scripts/list_urls.mjs /tmp를 실행합니다.
• URL 필터링: Blog post, news article, directory, competitor, existing customer를 제거합니다. company homepage만 유지합니다.

Research Phase

• Depth별 subagent당 company 수:
  • quick: subagent당 약 10개 회사
  • deep: subagent당 약 5개 회사
  • deeper: subagent당 약 2-3개 회사
• 각 subagent는 chained heredoc을 사용한 단일 Bash call로 모든 markdown file을 {OUTPUT_DIR}에 직접 씁니다.

Sizing Formula

search_queries = ceil(requested_companies / 35)
discovery_subagents = search_queries
expected_urls = search_queries * 20

quick:  research_subagents = ceil(expected_urls / 10)
deep:   research_subagents = ceil(expected_urls / 5)
deeper: research_subagents = ceil(expected_urls / 3)

Error Handling

• subagent가 실패하면 error를 log하고 남은 batch를 계속 진행합니다.
• 한 wave에서 subagent의 50% 초과가 실패하면 멈추고 사용자에게 알립니다.
• extract_page.mjs는 browse cloud fetch → browse get markdown fallback을 내부적으로 이미 처리합니다. 그래도 empty BODY와 함께 FETCH_OK: false를 반환하면 회사를 skip하고 product_description을 Unknown으로 표시합니다(추측하지 않음).

Report + CSV Compilation

모든 research subagent가 완료되면 한 command로 HTML report와 CSV를 compile합니다.

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

이 script는 다음을 수행합니다.

• {OUTPUT_DIR}의 모든 .md file을 읽습니다.
• YAML frontmatter + body section을 parse합니다.
• Normalized company name으로 deduplicate합니다(가장 높은 ICP score 유지).
• {OUTPUT_DIR}/index.html 생성 — 점수화된 overview page
• {OUTPUT_DIR}/companies/{slug}.html 생성 — 회사별 page 하나
• {OUTPUT_DIR}/results.csv 생성 — sheets/CRM용 spreadsheet
• index.html을 default browser에서 엽니다(--open flag).
• JSON summary를 stderr에 출력합니다.