Поиск потенциальных участников мероприятий

Введите URL-адрес конференции → получите ранжированный список людей, с которыми должен поговорить AE, с обоснованием «почему стоит связаться» для каждого человека.

Требуется: переменная среды BROWSERBASE_API_KEY и установленная командная строка browse (npm install -g browse). Используйте browse cloud ... для вызовов API и browse open / browse get markdown для страниц докладчиков с большим количеством JS-кода.

Правила работы с путями: во всех командах 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 для импорта в систему холодных исходящих звонков.

ВАЖНО — Ограничения инструмента (применимы к главному агенту И всем субагентам):

• Все поиски в Интернете: используйте облачный поиск. НИКОГДА не используйте WebSearch.
• Извлечение всего содержимого страниц: используйте узел {SKILL_DIR}/scripts/extract_page.mjs "". Этот скрипт выполняет запрос через `browse cloud fetch --output`, анализирует заголовок, мета-теги и видимый текст тела страницы, а в случае сбоя запроса или возврата скудного контента, отображаемого с помощью JS, автоматически переключается на `browse get markdown `. НИКОГДА не создавайте вручную конвейер из `browse cloud fetch` и `sed`. НИКОГДА не используйте WebFetch.
• Все результаты исследования: субагенты создают по одному файлу Markdown на каждую компанию ИЛИ на каждого человека в папке {OUTPUT_DIR}/companies/{slug}.md или {OUTPUT_DIR}/people/{slug}.md с использованием bash heredoc. НИКОГДА не используйте инструмент 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), отрасли или причине должности человека (role_reason) на основе шрифтов, фреймворка, системы дизайна или типографики сайта. Эти элементы носят косметический характер и ничего не говорят о том, что продает компания или чем занимается человек.
• НИКОГДА не допускайте, чтобы собственный ICP пользователя просачивался в описание целевого объекта. Если вы не знаете, чем занимается целевой объект, напишите «Неизвестно» — не сопоставляйте его с ICP по шаблону.
• Описание продукта (product_description) ДОЛЖНО цитировать или перефразировать конкретную фразу из вывода файла extract_page.mjs. Если ни один из элементов TITLE/META/OG/HEADINGS/BODY не содержит узнаваемого описания продукта, укажите «Неизвестно» — контент главной страницы недоступен, а значение icp_fit_score ограничьте значением 3.
• Хук человека ДОЛЖЕН цитировать или перефразировать конкретный результат из поискового облака (название подкаста, заголовок блога, репозиторий GitHub, аннотация доклада). Если за последние 6 месяцев не было публичных сигналов, используйте контекст мероприятия (название его доклада на данном мероприятии).

КРИТИЧЕСКИ ВАЖНО — Сведите к минимуму запросы на разрешение:

• Подкагенты ДОЛЖНЫ объединять ВСЕ записи файлов в ОДИН вызов Bash с использованием цепочки heredoc. Один вызов Bash = один запрос на разрешение.
• Объединяйте ВСЕ поиски и ВСЕ запросы данных в отдельные вызовы 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
8. Дополнить список докладчиков — спросить пользователя: только те, кто соответствует ICP (по умолчанию) или все докладчики
9. Составление отчёта — HTML + CSV, открытие в браузере

Пользователь запускает навык с помощью URL-адреса, например /event-prospecting . Проанализируйте 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 , используйте этот слэг.
2. В противном случае перечислите файлы profiles/*.json, исключив example.json. Если существует ровно один профиль, используйте его (и сообщите пользователю, какой именно). Если существует несколько, спросите у пользователя (в обычном чате), какой из них выбрать.
3. Если профилей нет, выдайте громкое сообщение об ошибке и предложите пользователю создать профиль (скопировать файл profiles/example.json в каталог profiles/.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/.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 , чтобы выбрать один из них."
    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. Они дословно вставляются в каждый последующий запрос субагента.

Шаг 2: Разведка

Определение платформы события и стратегии извлечения данных. Одна команда:

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

Создаёт файл {OUTPUT_DIR}/recon.json с данными о платформе, стратегии и (для 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 (один докладчик на строку) и файл 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 (по одной компании в строке, без дубликатов, отсортированный). Этот шаг носит информационный характер — убедитесь, что количество компаний выглядит разумным, прежде чем приступать к дальнейшей обработке:

wc -l {OUTPUT_DIR}/seed_companies.txt

Ожидаемое значение: примерно 0,4–0,6× от количества докладчиков (в большинстве мероприятий в среднем ~2 докладчика на компанию, некоторые компании направляют 5 и более, многие — 1).

Шаг 5: Отбор по ICP

Быстрая проверка — один вызов инструмента на компанию, без углублённого исследования. Оцените каждую компанию из seed_companies.txt по ICP пользователя и запишите краткую заметку о сортировке в файл companies/{slug}.md. Компании с icp_fit_score >= --icp-threshold (по умолчанию 6) проходят к глубокому исследованию на шаге 7; остальные остаются в виде заготовки отбора.

Схема распределения: разделить файл seed_companies.txt на партии по ~10 и распределить N под-агентов в ОДНОЙ партии Agent (несколько вызовов инструмента Agent в одном сообщении). Каждый под-агент запускает промпт из файла references/workflow.md → раздел «ICP Triage». Жёсткое ограничение: 1 вызов инструмента на компанию (только extract_page.mjs на главной странице), обеспечиваемое шаблоном комментариев # browse call N/1.

# Создание файлов партий: каждая строка партии имеет формат «имя|предполагаемая_главная_страница|slug».
# extract_event.mjs выдает только НАЗВАНИЯ компаний (без URL), поэтому мы преобразуем их в slug и предполагаем,
# что https://{slug-без-пробелов}.com является канонической главной страницей. Подагент сортировки
# может записывать product_description: «Неизвестно — контент главной страницы недоступен»
# и устанавливать оценку ограничения на 3, если предполагаемый URL возвращает ошибку 404 — это задокументированный резервный вариант в
# workflow.md (правило 3 подсказки ICP Triage). Использование реального поиска по облаку просмотров для
# обнаружения 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 на одно сообщение; вторая волна для остальных)
ls {OUTPUT_DIR}/_batch_triage_* | wc -l

Затем в одном сообщении отправьте по одному вызову агента на каждую партию (до 6 параллельно; последующие волны — после возвращения первой). Каждый агент получает запрос из файла references/workflow.md → «ICP Triage» с следующими заменами перед отправкой:

• {SKILL_DIR} → полный буквальный путь к набору навыков (например, /Users/jay/skills/skills/event-prospecting)
• {OUTPUT_DIR} → полный буквальный путь к папке вывода
• {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION} → из загруженного профиля
• {EVENT_NAME} → title из файла recon.json
• {COMPANY_LIST} → содержимое пакетного файла (например, cat {OUTPUT_DIR}/_batch_triage_aa)
• {TOTAL} → количество строк в этом пакете (подставить в вызов #browse N/{TOTAL})

Отправка агента (шаблон, повторять для каждой партии в одном сообщении):

Agent(
  description: "ICP triage batch aa",
  prompt: ,
  subagent_type: "general-purpose"
)
Agent(
  description: "ICP triage batch ab",
  prompt: ,
  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   # из флага --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

Ожидаемое значение: 20–40 % от seed_companies.txt. Если коэффициент выживаемости < 10 %, возможно, пороговое значение слишком высокое или описание ICP слишком узкое — вывести предупреждение для пользователя.

Шаг 7: Углублённое исследование

Полный план → Исследование → Синтез только для компаний, соответствующих критериям ICP. Жесткий лимит: не более 5 вызовов инструментов на каждую компанию (извлечение с главной страницы + 2–3 поиска по подвопросам + 1–2 дополнительных запроса). Субагенты ПЕРЕЗАПИСЫВАЮТ существующий заготовленный файл triage компании/{slug}.md более подробной версией, подготовленной в ходе углубленного исследования (параметр frontmatter : triage_only = false).

Шаблон отправки: разделить icp_fits.txt на партии по ~5 (по умолчанию в глубоком режиме) и распределить по одному агенту на партию в ОДНОМ сообщении (до 6 агентов на сообщение). Каждый агент получает подсказку из references/workflow.md → «Deep Research» со следующими заменами:

• {SKILL_DIR}, {OUTPUT_DIR}, {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}
• {EVENT_NAME} (из .title файла recon.json ), {EVENT_CONTEXT} (направление / тема, выведенные вручную из главной страницы события)
• {COMPANY_LIST} → содержимое пакетного файла (каждая строка slug|website)

# Создать пары {company-slug|website} путем чтения вступительной информации из каждого заготовленного файла triage
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(
  description: "Партия глубокого исследования aa",
  prompt: ,
  subagent_type: "general-purpose"
)
Agent(
  description: "Партия глубоких исследований ab",
  prompt: ,
  subagent_type: "general-purpose"
)
... до 6 на одно сообщение; вторая волна после возврата первой

После того как все субагенты вернутся, проверьте, существуют ли файлы глубокого исследования и имеют ли они triage_only: false:

grep -l "triage_only: false" {OUTPUT_DIR}/companies/*.md | wc -l
# Должно равняться wc -l icp_fits.txt

Шаг 8: Дополнение информации о докладчиках

Для каждого человека: соберите URL-адрес LinkedIn, информацию о недавней активности (подкаст / блог / выступление / GitHub / X) и создайте файл people/{slug}.md. Жесткий лимит: 4 вызова инструмента на человека, три направления:

1. обзорный поиск в облаке «{имя} {компания} linkedin» (всегда)
2. поиск в облаке «{имя} подкаст ИЛИ выступление ИЛИ блог 2026» (углублённый+)
3. обзорный поиск в облаке «{имя} github» (более глубокий)
4. обзорный поиск в облаке «{имя} site:x.com OR site:twitter.com» (более глубокий, по мере возможности)

Быстрый режим: полностью пропустить шаг 8. Глубокий режим: каналы 1–2. Режим «ещё глубже»: каналы 1–4.

Шаг 8a — Спросите пользователя: объем обогащения

Перед отправкой вычислите количество кандидатов по двум вариантам и попросите пользователя выбрать. По умолчанию используется только ICP-fit (быстрее, дешевле, то, что хотят большинство пользователей); обогащение каждого говорящего доступно по желанию, поскольку стоимость растет линейно с количеством обогащенных людей.

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 (глубокий) или 4 (ещё глубже) — соответствует {DEPTH}
LANES=2   # или 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 минут с сотнями вызовов инструмента.

Шаг 8b — Фильтрация и пакетная обработка

# Создать файл _people_to_enrich.jsonl на основе 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(`Дополняем данные для ${keep.length} из ${lines.length} докладчиков`);
'
fi

# Разбить на партии по ~5 человек
split -l 5 {OUTPUT_DIR}/_people_to_enrich.jsonl {OUTPUT_DIR}/_batch_people_

Затем в одном сообщении отправьте по одному вызову агента на каждую партию (до 6 на сообщение) с подсказкой из references/workflow.md → «Person Enrichment». Подсказка каждого субагента должна включать:

• {SKILL_DIR}, {OUTPUT_DIR}, {DEPTH} (deep | deeper)
• {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}
• {EVENT_NAME} (из .title файла recon.json )
• {LANES} → 2 для режима deep, 4 для режима deeper (подставляется в вызов # browse N/{LANES})
• {PEOPLE_BATCH} → содержимое _batch_people_aa (каждая строка — запись JSON из people.jsonl)

Отправка агента (каркас, повторяется для каждого пакета в одном сообщении):

Agent(
  description: "Пакетное обогащение данных о лицах aa",
  prompt: ,
  subagent_type: "general-purpose"
)
Agent(
  description: "Партия ab по обогащению данных о лицах",
  prompt: ,
  subagent_type: "general-purpose"
)
... до 6 на одно сообщение

После того как все субагенты вернут результаты, проверьте наличие файлов с данными о людях:

ls {OUTPUT_DIR}/people/*.md | wc -l
# Должно равняться wc -l _people_to_enrich.jsonl

Шаг 9: Сборка отчёта

Сгенерируйте 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 — таблица, готовая для холодных исходящих звонков

Затем представьте сводку в чате:

## Поиск потенциальных клиентов на мероприятии завершён — {Название мероприятия}

- **Общее количество выявленных докладчиков**: {count}
- **Уникальные компании**: {count}
- **Соответствие ICP (оценка ≥ {пороговое значение})**: {count}
- **Дополнительные данные о докладчиках**: {count}
- **Распределение оценок** (компании):
  - Сильное соответствие (8–10): {count}
  - Частичное соответствие (5–7): {count}
  - Слабое соответствие (1–4): {count}
- **Отчет открыт в браузере**: {OUTPUT_DIR}/index.html

Показать 5 лучших карточек людей в виде таблицы Markdown, отсортированной по баллу ICP компании, а затем предложить:

• Настроить параметр --icp-threshold и повторить шаги 6–9
• Экспортировать CSV-файл в CRM