Generated banner for Event Prospecting
Generated logo for Event Prospecting

Event Prospecting

BrowserbaseOfficialCreated by browserbase

  • Skill
  • Workflow
  • Business and productivity
  • MIT
  • Low risk
  • Has scripts

From the author

Event prospecting skill. Takes a conference / event speakers URL, extracts the people, filters their companies against the user's ICP, then deep-researches only the speakers at ICP-fit companies. Outputs a person-first HTML report where each card answers "why should the AE talk to this person?" with all public links and a one-click DM opener. Use when the user wants to: (1) find leads at a specific conference, (2) prep for an event, (3) research event speakers, (4) build a target list from a sponsor/exhibitor page, (5) scrape conference speakers and rank by ICP fit. Triggers: "find leads at {event}", "research speakers at", "prospect this conference", "stripe sessions leads", "ai engineer summit prospects", "event prospecting", "scrape conference speakers", "who should I meet at".
— the description by browserbase

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill streamlines event preparation by automating the identification and research of conference speakers. It extracts speaker lists from event websites, filters companies based on a user-defined Ideal Customer Profile (ICP), and performs deep research on high-fit targets. The final output is a structured HTML report containing actionable insights, public links, and DM openers for each prospect, designed to help account executives prioritize their outreach efforts.

What it does

  • Extracts speaker lists from various event platforms using automated detection.
  • Filters companies against a user-provided ICP to identify high-potential leads.
  • Performs deep research on ICP-fit companies and their respective speakers.
  • Generates a person-first HTML report with company-grouped cards.
  • Provides a CSV file ready for cold-outbound import.
  • Creates one-click DM openers based on public signals and event context.

When to use it

  • When you need to identify and rank leads at a specific conference.
  • When preparing for an upcoming event to maximize networking efficiency.
  • When you want to research event speakers to personalize your outreach.
  • When building a target list from event sponsor or exhibitor pages.

Advantages

  • Saves significant time by automating manual research and data extraction.
  • Ensures outreach is focused on high-fit prospects based on your specific ICP.
  • Provides context-rich insights that help craft personalized, relevant messages.
  • Standardizes the prospecting workflow across different events and platforms.

Usage examples

“find leads at {event}”
The agent extracts speakers from the specified event URL, filters them by your ICP, and generates an HTML report of high-fit prospects.
“research speakers at {event}”
The agent performs deep research on speakers associated with companies that match your ICP, providing a rationale for why you should reach out.
“prospect this conference”
The agent initiates the full prospecting pipeline, from event platform detection to the final compilation of an outreach-ready report.
“who should I meet at {event}”
The agent identifies the most relevant speakers based on your profile and presents them in a ranked list with actionable outreach hooks.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/browserbase/event-prospecting/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip event-prospecting.zip -d .agents/skills

Documentation by browserbase

Event Prospecting

Take a conference URL → get a ranked list of people the AE should talk to, with a "why reach out" rationale per person.

Required: BROWSERBASE_API_KEY env var and the browse CLI installed (npm install -g browse). Use browse cloud ... for API calls and browse open / browse get markdown for JS-heavy speaker pages.

Path rules: Always use the full literal path in all Bash commands — NOT ~ or $HOME (both trigger "shell expansion syntax" approval prompts). Resolve the home directory once and use it everywhere. When constructing subagent prompts, replace {SKILL_DIR} with the full literal path (typically /Users/jay/skills/skills/event-prospecting).

Output directory: All event prospecting output goes to ~/Desktop/{event_slug}_prospects_{YYYY-MM-DD-HHMM}/. Final deliverable is index.html (people grouped by company, ranked by company ICP), with companies.html and people.html (filterable) as alternate views, plus results.csv for cold-outbound import.

CRITICAL — Tool restrictions (applies to main agent AND all subagents):

  • All web searches: use browse cloud search. NEVER use WebSearch.

  • All page content extraction: use node {SKILL_DIR}/scripts/extract_page.mjs "<url>". This script fetches via browse cloud fetch --output, parses title + meta tags + visible body text, and automatically falls back to browse get markdown when fetch fails or returns thin JS-rendered content. NEVER hand-roll a browse cloud fetch | sed pipeline. NEVER use WebFetch.

  • All research output: subagents write one markdown file per company OR per person to {OUTPUT_DIR}/companies/{slug}.md or {OUTPUT_DIR}/people/{slug}.md using bash heredoc. NEVER use the Write tool or python3 -c. See references/example-research.md for both file formats.

  • Report compilation: use node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --open.

  • Subagents must use ONLY the Bash tool. No other tools allowed.

  • HARD TOOL-CALL CAPS: ICP triage = 1 call/company; deep research = 5 calls/company; person enrichment = 4 calls/person. See references/workflow.md for enforcement detail.

CRITICAL — Anti-hallucination rules (applies to main agent AND all subagents):

  • NEVER infer product_description, industry, or a person's role_reason from a site's fonts, framework, design system, or typography. These are cosmetic and say nothing about what the company sells or what the person does.

  • NEVER let the user's own ICP leak into a target's description. If you don't know what the target does, write Unknown — do not pattern-match them onto the ICP.

  • product_description MUST quote or paraphrase a specific phrase from extract_page.mjs output. If none of TITLE/META/OG/HEADINGS/BODY yield a recognizable product statement, write Unknown — homepage content not accessible and cap icp_fit_score at 3.

  • A person's hook MUST quote or paraphrase a specific finding from a browse cloud search result (podcast title, blog headline, GitHub repo, talk abstract). If no public signal exists in the last 6 months, fall back to event-context (their talk title at this event).

CRITICAL — Minimize permission prompts:

  • Subagents MUST batch ALL file writes into a SINGLE Bash call using chained heredocs. One Bash call = one permission prompt.

  • Batch ALL searches and ALL fetches into single Bash calls using && chaining.

Pipeline Overview

Follow these 10 steps in order. Do not skip steps or reorder.

  1. Setup — output dir + clean slate

  2. Load profile — read profiles/{user_slug}.json

  3. Recon — detect event platform

  4. Extract people — people.jsonl

  5. Group by company — seed_companies.txt

  6. ICP triage — fast company-level scoring (1 call/company)

  7. Filter — companies with icp_fit_score >= --icp-threshold

  8. Deep research — full Plan→Research→Synthesize on ICP fits

  9. Enrich speakers — ask user: ICP-fit only (default) or all speakers

  10. Compile report — HTML + CSV, open in browser

The user invokes the skill with a URL like /event-prospecting <URL>. Parse EVENT_URL from that invocation message. Defaults: DEPTH=deep, ICP_THRESHOLD=6. The USER_SLUG (ICP profile) is auto-resolved in Step 1 from whatever profile files exist locally — there is no built-in default profile. Do NOT ask the user to confirm the URL — they already gave you it.


Step 0: Setup Output Directory

Derive the output directory from the URL the user gave you. Do NOT hardcode any event name.

# 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"

Use the full literal home path — never ~ or $HOME. Pass {OUTPUT_DIR} as the full literal path to all subagent prompts.

Step 1: Load User Profile

The profile defines the ICP that ICP triage and deep research score against. Load from {SKILL_DIR}/profiles/{user_slug}.json (interchangeable across all GTM skills — same shape as company-research). example.json is a template, not a real profile — never use it.

DO NOT look outside {SKILL_DIR}/profiles/ for profiles — never reach into other skills' directories. If a profile is needed elsewhere, the user copies it explicitly.

Resolution order:

  1. If the user invoked with --user-company <slug>, use that slug.

  2. Else, list profiles/*.json excluding example.json. If exactly one profile exists, use it (and tell the user which one). If multiple exist, ask the user (plain chat) which one.

  3. If zero profiles exist, fail loudly and instruct the user to create one (copy profiles/example.json to profiles/<your_slug>.json and fill it in, or run the company-research skill which builds one automatically).

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

The profile yields: company, product, icp_description, existing_customers. These get embedded verbatim in every subagent prompt downstream.

Step 2: Recon

Detect the event platform and extraction strategy. One command:

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

Writes {OUTPUT_DIR}/recon.json with platform, strategy, and (for Next.js) nextDataPaths. See references/event-platforms.md for the platform catalog and detection priority.

Expected outcomes:

  • Stripe Sessions class (Next.js): platform: "next-data", 1-3 paths

  • Sessionize: platform: "sessionize"

  • Lu.ma / Eventbrite: platform: "luma" | "eventbrite"

  • Anything else: platform: "custom", strategy: "markdown" (best-effort fallback)

Step 3: Extract People

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

Reads recon.json, dispatches to the platform-specific extractor, writes people.jsonl (one speaker per line) and seed_companies.txt (deduped companies).

The --user-company flag also drops the host-org's own employees (a Stripe-hosted event drops Stripe employees) and the user's own employees from the speaker list — those aren't prospects.

Sanity-check the output:

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

If people.jsonl is empty or under ~10 lines, recon picked the wrong platform — see references/event-platforms.md and re-run with adjusted strategy.

Step 4: Group by Company

extract_event.mjs emits seed_companies.txt already (one company per line, deduped, sorted). This step is informational — verify the count looks reasonable before fanning out:

wc -l {OUTPUT_DIR}/seed_companies.txt

Expected: roughly 0.4-0.6× the speaker count (most events have ~2 speakers per company on average, some companies send 5+, many send 1).

Step 5: ICP Triage

Fast pass — one tool call per company, no deep research. Score every company in seed_companies.txt against the user's ICP and write a thin triage stub to companies/{slug}.md. Companies with icp_fit_score >= --icp-threshold (default 6) advance to Step 7's deep research; the rest stay as triage stubs.

Dispatch pattern: split seed_companies.txt into batches of ~10 and fan out N subagents in a SINGLE Agent batch (multiple Agent tool calls in one message). Each subagent runs the prompt from references/workflow.md → "ICP Triage" section. Hard cap: 1 tool call per company (just extract_page.mjs on the homepage), enforced via the # browse call N/1 comment pattern.

# 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

Then in a single message, dispatch one Agent call per batch (up to 6 in parallel; subsequent waves after the first returns). Each Agent gets the prompt from references/workflow.md → "ICP Triage" with these substitutions before sending:

  • {SKILL_DIR} → full literal skill path (e.g. /Users/jay/skills/skills/event-prospecting)

  • {OUTPUT_DIR} → full literal output path

  • {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION} → from the loaded profile

  • {EVENT_NAME} → recon.json .title

  • {COMPANY_LIST} → contents of the batch file (e.g. cat {OUTPUT_DIR}/_batch_triage_aa)

  • {TOTAL} → number of lines in this batch (substitute into # browse call N/{TOTAL})

Agent dispatch (skeleton, repeat per batch in one message):

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

After all subagents return, verify every company in seed_companies.txt has a corresponding companies/{slug}.md:

ls {OUTPUT_DIR}/companies/*.md | wc -l
# Should equal `wc -l {OUTPUT_DIR}/seed_companies.txt`

Clean up the batch files: rm {OUTPUT_DIR}/_batch_triage_*.

Step 6: Filter by ICP Threshold

Read each companies/*.md frontmatter, keep those with icp_fit_score >= 6 (or whatever --icp-threshold is). Write the surviving company slugs to {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

Expected: 20-40% of seed_companies.txt. If the survival rate is < 10%, the threshold may be too high or the ICP description too narrow — surface a warning to the user.

Step 7: Deep Research

Full Plan→Research→Synthesize on ICP-fit companies only. Hard cap: 5 tool calls per company (homepage extract + 2-3 sub-question searches + 1-2 supplementary fetches). Subagents OVERWRITE the existing companies/{slug}.md triage stub with the richer deep-research version (frontmatter triage_only: false).

Dispatch pattern: split icp_fits.txt into batches of ~5 (deep mode default) and fan out one Agent per batch in a SINGLE message (up to 6 Agents per message). Each Agent gets the prompt from references/workflow.md → "Deep Research" with these substitutions:

  • {SKILL_DIR}, {OUTPUT_DIR}, {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}

  • {EVENT_NAME} (from recon.json .title), {EVENT_CONTEXT} (track / topic, manually inferred from the event homepage)

  • {COMPANY_LIST} → contents of the batch file (each line 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 dispatch (skeleton, repeat per batch in one message):

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

After all subagents return, verify the deep-research files exist and have triage_only: false:

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

Step 8: Enrich Speakers

Per person: harvest LinkedIn URL, recent activity (podcast / blog / talk / GitHub / X), and write people/{slug}.md. Hard cap: 4 tool calls per person, three lanes:

  1. browse cloud search "{name} {company} linkedin" (always)

  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, best-effort)

Quick mode: skip Step 8 entirely. Deep mode: lanes 1-2. Deeper mode: lanes 1-4.

Step 8a — Ask the user: scope of enrichment

Before dispatching, compute the two candidate counts and ask the user to choose. The default is ICP-fit only (faster, cheaper, what most users want); enriching every speaker is opt-in because cost scales linearly with people enriched.

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"

Then ask via AskUserQuestion — clean two-option choice with the quantified cost on each:

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" }
    ]
  }
])

Save the chosen scope as ENRICH_SCOPE=icp_fits or ENRICH_SCOPE=all. If the user picks "All speakers" and TOTAL × LANES > 600, print a warning and ask once more — that's a 10+ minute run with hundreds of tool calls.

Step 8b — Filter and batch
# 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_

Then in a single message, dispatch one Agent call per batch (up to 6 per message) with the prompt from references/workflow.md → "Person Enrichment". Each subagent's prompt should include:

  • {SKILL_DIR}, {OUTPUT_DIR}, {DEPTH} (deep | deeper)

  • {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}

  • {EVENT_NAME} (from recon.json .title)

  • {LANES} → 2 for deep mode, 4 for deeper mode (substituted into # browse call N/{LANES})

  • {PEOPLE_BATCH} → contents of _batch_people_aa (each line a JSON record from people.jsonl)

Agent dispatch (skeleton, repeat per batch in one message):

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

After all subagents return, verify the people files exist:

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

Step 9: Compile Report

Generate the company-grouped HTML index, alternate views, and CSV in one command:

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

This generates:

  • {OUTPUT_DIR}/index.html — people grouped by company, ranked by company ICP score (opens in browser)

  • {OUTPUT_DIR}/people.html — filterable speaker list (alternate view)

  • {OUTPUT_DIR}/companies.html — ICP-ranked company table with attendees

  • {OUTPUT_DIR}/results.csv — cold-outbound-ready spreadsheet

Then present a summary in chat:

## 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

Show the top 5 people cards as a markdown table sorted by company ICP score, then offer to:

  • Adjust --icp-threshold and re-run Steps 6-9

  • Export the CSV to a CRM

Files

references/example-research.md

Example Research Files

Event-prospecting writes TWO kinds of markdown files:

  1. Company files — one per company in seed_companies.txt, written to {OUTPUT_DIR}/companies/{slug}.md. Comes in two flavors: triage stubs (Step 5) and deep-research files (Step 7).

  2. Person files — one per speaker at an ICP-fit company, written to {OUTPUT_DIR}/people/{slug}.md. Created in Step 8.

The YAML frontmatter contains structured fields for report compilation. The body contains human-readable research.

{OUTPUT_DIR} is the per-run Desktop directory set up by the main agent in Step 0 (e.g., /Users/jay/Desktop/{event_slug}_prospects_2026-04-25-2030/).


Company File — Triage Stub (Step 5 output)

Every company in seed_companies.txt gets one of these. It captures a 1-call, ICP-only assessment.

---
company_name: OpenAI
website: https://openai.com
product_description: AI lab building safe AGI; ChatGPT, GPT API, ChatGPT Agent
icp_fit_score: 9
icp_fit_reasoning: AI agents at scale need cloud browser infrastructure; ChatGPT Agent shipped Mar 2026
triage_only: true
event_context: Stripe Sessions 2026 — featured speaker on AI track
---

## Triage Notes
Homepage: "ChatGPT, GPT API, and ChatGPT Agent — AI tools and APIs for everyone."
Score 9 because ChatGPT Agent ships browser-using AI agents at consumer scale — the canonical fit for browser infrastructure.

Required fields: company_name, website, icp_fit_score, icp_fit_reasoning, triage_only: true.


Company File — Deep Research (Step 7 output)

When a company's icp_fit_score >= --icp-threshold, Step 7's deep research overwrites the triage stub with this richer version. triage_only flips to false.

---
company_name: OpenAI
website: https://openai.com
product_description: Foundational AI lab; products span ChatGPT (consumer chat), GPT API (developer access), and ChatGPT Agent (browser-using autonomous agent)
industry: AI / Foundation Models
target_audience: Consumers, developers, enterprise — multi-segment
key_features: ChatGPT Agent | GPT-5 API | Sora video | enterprise data residency
icp_fit_score: 9
icp_fit_reasoning: ChatGPT Agent (Mar 2026) is a browser-using agent at consumer scale — directly addresses the "agents need a browser" wedge. Plus enterprise customers ship internal agents on top of GPT API.
employee_estimate: 3000+
funding_info: $11.3B raised; reported $300B valuation 2026
headquarters: San Francisco, CA
triage_only: false
event_context: Stripe Sessions 2026 — Greg Brockman featured speaker, Agents track
event_relevance: Three OpenAI speakers across the Agents and Infra tracks; ChatGPT Agent demo expected at the event
---

## Product
Foundational AI lab. Three product surfaces: ChatGPT (consumer/team chat), GPT API (developer platform), ChatGPT Agent (autonomous browsing agent that completes multi-step tasks). Recently shipped Sora 2 for video.

## Research Findings
- **[high]** ChatGPT Agent launched Mar 2026 — autonomous web-browsing agent that books, shops, and researches on user's behalf (source: openai.com/index/chatgpt-agent)
- **[high]** Stripe Sessions 2026 keynote includes Greg Brockman on the Agents track (source: stripesessions.com/speakers)
- **[medium]** Hiring across "Agent Reliability" team — 12 open roles for browser-automation engineers (source: openai.com/careers, search 2026-04)
- **[medium]** Reported partnership exploration with infrastructure providers for agent runtime (source: The Information, 2026-03)

## Event Relevance
Three speakers at Stripe Sessions across Agents and Infra tracks. ChatGPT Agent is the canonical use-case for browser-infrastructure-as-a-product. Pitch angle: durability + scale guarantees the in-house Browserbase-equivalent can't easily match.

Additional fields vs the stub: industry, target_audience, key_features (pipe-separated), employee_estimate, funding_info, headquarters, event_relevance.

Body sections: ## Product, ## Research Findings, ## Event Relevance.


Person File (Step 8 output)

Only created for speakers at ICP-fit companies (those whose company file has triage_only: false after Step 7).

---
name: Greg Brockman
slug: greg-brockman
company: OpenAI
company_slug: openai
title: President & Co-founder
image: https://cdn.example.com/speakers/greg-brockman.jpg
links:
  linkedin: https://www.linkedin.com/in/thegdb/
  x: https://x.com/gdb
  github: https://github.com/gdb
  blog: null
  podcast: https://lexfridman.com/greg-brockman/
hook: Recent Lex Fridman conversation on agent reliability — direct fit for the browser-infrastructure durability story
dm_opener: |
  Hey Greg — caught your Lex conversation on agent reliability and the
  "agents are bottlenecked on the browser" framing landed hard. We run
  the cloud-browser layer that ChatGPT Agent's competitors are shipping
  on. Worth a 15-min walkthrough before Sessions?
role_reason: Co-founder, sets infrastructure direction across product surfaces
event_name: Stripe Sessions 2026
event_context: Panelist, Agents track ("From demo to dependable: making agents reliable")
icp_fit_score: 9
icp_fit_reasoning: AI agents at scale need cloud browser infrastructure; ChatGPT Agent shipped Mar 2026
enriched_at: 2026-04-25T20:30:00Z
---

## Why reach out
- **Why the company**: ChatGPT Agent is the canonical browser-infra customer — see `companies/openai.md`
- **Why the person**: Co-founder; sets infra direction; specifically called out agent reliability on Lex (Mar 2026)
- **Hook**: Lex Fridman conversation on agent reliability (45 min, dropped 2026-03-12)

## Public links
- LinkedIn: https://www.linkedin.com/in/thegdb/
- X: https://x.com/gdb
- GitHub: https://github.com/gdb (OpenAI / personal)
- Podcast: https://lexfridman.com/greg-brockman/

## Recent activity
- **[high]** Lex Fridman podcast episode on agent reliability, Mar 2026 (source: lexfridman.com/greg-brockman)
- **[medium]** GitHub activity: contributed to openai/chatgpt-agent-evals (source: github.com/gdb)
- **[medium]** X thread on "the bottleneck for agents is the browser, not the model" — Apr 2026 (source: x.com/gdb)

Required fields: name, slug, company, links (object), hook, dm_opener, role_reason, event_name, event_context, icp_fit_score.

Body sections: ## Why reach out (3 bullets that mirror the card), ## Public links, ## Recent activity (findings list with confidence levels).


Field Rules

Company files
  • key_features: pipe-separated (|) list, NOT a JSON array

  • icp_fit_score: integer 1-10

  • icp_fit_reasoning: one line, references specific findings

  • triage_only: boolean (true for stubs, false after deep research)

  • event_context: how this company shows up at the event (sponsor tier, speaker count, track topics)

  • Filename: {OUTPUT_DIR}/companies/{slug}.md where slug is lowercase, hyphenated

Person files
  • image: speaker headshot URL extracted from the event site (preserved verbatim from the people.jsonl input record). May be null on platforms that don't expose it.

  • links: YAML object with keys linkedin, x, github, blog, podcast. Use null when not found, not empty string.

  • hook: one sentence, sourced from a specific finding (event-context, recent activity, or company-context). Never inferred from memory.

  • dm_opener: 2-3 sentences, multi-line YAML string with | pipe. References the hook, names a wedge tie-in, ends with a soft CTA.

  • icp_fit_score is INHERITED from the corresponding companies/{company_slug}.md — keeps cards rankable in the index.

  • Filename: {OUTPUT_DIR}/people/{slug}.md where slug is the lowercased + hyphenated person name (e.g. greg-brockman.md).

Both
  • One file per entity. If a subagent encounters a duplicate, OVERWRITE with richer data (e.g. Step 7 overwrites Step 5's triage stub for the same company).


Writing via Bash Heredoc

Subagents write these files using bash heredoc to avoid security prompts. Use the full literal {OUTPUT_DIR} path — no ~ or $HOME:

cat << 'PERSON_MD' > /Users/jay/Desktop/stripesessions_prospects_2026-04-25-2030/people/greg-brockman.md
---
name: Greg Brockman
slug: greg-brockman
...
---

## Why reach out
...
PERSON_MD

Use 'PERSON_MD' (quoted) as the delimiter to prevent shell variable expansion. Use 'COMPANY_MD' for company files.

IMPORTANT: Write ALL files in a SINGLE Bash call using chained heredocs to minimize permission prompts. One subagent batch (~5 people) = one Bash invocation = one permission prompt.

cat << 'PERSON_MD' > {OUTPUT_DIR}/people/greg-brockman.md
---
...
---
PERSON_MD
cat << 'PERSON_MD' > {OUTPUT_DIR}/people/sam-altman.md
---
...
---
PERSON_MD

Chained heredocs in one bash call. The subagent reports back ONLY a count, never raw content.

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Names Claude Code tools, Needs an API key, Needs Python, Needs Node.js

The author says: Requires browse CLI (`npm install -g browse`) and BROWSERBASE_API_KEY env var. The same `browse` binary covers both API commands and JS-rendered page fallback.

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
browserbase
Publisher
Browserbase (Official)
Source
browserbase/skills · skills/event-prospecting · commit 6811ca3
Licence
MIT License (redistribution allowed)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by browserbase or Browserbase.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download event-prospecting.zip