Prospección en eventos

Introduce la URL de una conferencia → obtén una lista ordenada de personas con las que el representante comercial debería ponerse en contacto, con una justificación de «por qué contactar» para cada persona.

Requisitos: la variable de entorno BROWSERBASE_API_KEY y la CLI de browse instalada (npm install -g browse). Utiliza browse cloud... para las llamadas a la API y browse open / browse get markdown para las páginas de ponentes con mucho código JS.

Reglas de ruta: utiliza siempre la ruta literal completa en todos los comandos de Bash —NO ~ ni $HOME (ambos activan mensajes de confirmación de «sintaxis de expansión de shell»). Resuelve el directorio de inicio una sola vez y utilízalo en todas partes. Al crear mensajes para los subagentes, sustituye {SKILL_DIR} por la ruta literal completa (normalmente /Users/jay/skills/skills/event-prospecting).

Directorio de salida: toda la salida de la prospección de eventos se guarda en ~/Desktop/{event_slug}_prospects_{AAAA-MM-DD-HHMM}/. El resultado final es index.html (personas agrupadas por empresa, clasificadas según el ICP de la empresa), con companies.html y people.html (filtrables) como vistas alternativas, además de results.csv para la importación de contactos en frío.

IMPORTANTE — Restricciones de la herramienta (se aplica al agente principal Y a todos los subagentes):

• Todas las búsquedas en la web: utiliza la búsqueda en la nube de Browse. NUNCA utilices WebSearch.
• Toda extracción de contenido de páginas: utiliza el nodo {SKILL_DIR}/scripts/extract_page.mjs "". Este script realiza la recuperación mediante «browse cloud fetch --output», analiza el título, las etiquetas meta y el texto visible del cuerpo, y recurre automáticamente a «browse get markdown» cuando la recuperación falla o devuelve contenido escaso renderizado en JS. NUNCA crees manualmente una cadena de comandos «browse cloud fetch | sed ». NUNCA utilices WebFetch.
• Todos los resultados de la investigación: los subagentes deben escribir un archivo Markdown por empresa O por persona en {OUTPUT_DIR}/companies/{slug}.md o {OUTPUT_DIR}/people/{slug}.md utilizando bash heredoc. NUNCA utilices la herramienta «Write» ni python3 -c. Consulta references/example-research.md para ver ambos formatos de archivo.
• Compilación del informe: utiliza el comando node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --open.
• Los subagentes deben utilizar ÚNICAMENTE la herramienta de Bash. No se permiten otras herramientas.
• LÍMITE MÁXIMO DE LLAMADAS: Triaje ICP = 1 llamada/empresa; investigación en profundidad = 5 llamadas/empresa; enriquecimiento de datos personales = 4 llamadas/persona. Consulta references/workflow.md para conocer los detalles de aplicación.

CRÍTICO — Normas contra las «alucinaciones» (se aplican al agente principal Y a todos los subagentes):

• NUNCA deduzcas la descripción del producto, el sector o la razón del cargo de una persona a partir de las fuentes, el marco de trabajo, el sistema de diseño o la tipografía de un sitio web. Estos son aspectos estéticos y no dicen nada sobre lo que vende la empresa o lo que hace la persona.
• NUNCA dejes que el propio ICP del usuario se filtre en la descripción de un destinatario. Si no sabes a qué se dedica el destinatario, escribe «Desconocido»; no lo compares con el ICP.
• «product_description» DEBE citar o parafrasear una frase concreta de la salida de «extract_page.mjs ». Si ninguno de los elementos TITLE/META/OG/HEADINGS/BODY ofrece una descripción del producto reconocible, escribe «Desconocido» —contenido de la página de inicio no accesible— y limita «icp_fit_score» a 3.
• El gancho de una persona DEBE citar o parafrasear un hallazgo específico de un resultado de búsqueda en la nube de navegación (título de un podcast, titular de un blog, repositorio de GitHub, resumen de una ponencia). Si no existe ninguna señal pública en los últimos 6 meses, recurre al contexto del evento (el título de su ponencia en dicho evento).

CRÍTICO — Minimizar las solicitudes de permiso:

• Los subagentes DEBEN agrupar TODAS las escrituras de archivos en una ÚNICA llamada a Bash utilizando heredocs encadenados. Una llamada a Bash = una solicitud de permiso.
• Agrupa TODAS las búsquedas y TODAS las recuperaciones en llamadas únicas de Bash utilizando el encadenamiento &&.

Descripción general del proceso

Sigue estos 10 pasos en orden. No te saltes ningún paso ni cambies el orden.

0. Configuración — directorio de salida + borrado completo
1. Cargar perfil: leer profiles/{user_slug}.json
2. Reconocimiento: detectar la plataforma de eventos
3. Extracción de personas: people.jsonl
4. Agrupar por empresa — seed_companies.txt
5. Clasificación ICP: puntuación rápida a nivel de empresa (1 llamada por empresa)
6. Filtrar — empresas con icp_fit_score >= --icp-threshold
7. Investigación en profundidad — proceso completo «Planificar→Investigar→Sintetizar» sobre la adecuación al ICP
8. Ampliar la lista de ponentes: preguntar al usuario si quiere solo los que encajan con el ICP (por defecto) o todos los ponentes
9. Compilar informe — HTML + CSV, abrir en el navegador

El usuario activa la skill con una URL como /event-prospecting . Analiza EVENT_URL a partir de ese mensaje de activación. Valores por defecto: DEPTH=deep, ICP_THRESHOLD=6. El USER_SLUG (perfil ICP) se resuelve automáticamente en el paso 1 a partir de los archivos de perfil que existan localmente; no hay ningún perfil predeterminado integrado. NO pidas al usuario que confirme la URL: ya te la ha facilitado.

Paso 0: Configuración del directorio de salida

Obtén el directorio de salida a partir de la URL que te ha facilitado el usuario. NO codifiques ningún nombre de evento de forma fija.

# EVENT_URL procede del mensaje de invocación (lo que el usuario haya escrito después de `/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"

Utiliza la ruta completa literal de inicio; nunca ~ ni $HOME. Pasa {OUTPUT_DIR} como la ruta completa literal a todas las solicitudes de los subagentes.

Paso 1: Cargar el perfil de usuario

El perfil define el ICP con respecto al cual se realiza la clasificación y la puntuación de investigación en profundidad del ICP. Cárgalo desde {SKILL_DIR}/profiles/{user_slug}.json (intercambiable entre todas las habilidades de GTM; tiene la misma estructura que company-research). example.json es una plantilla, no un perfil real; nunca lo utilices.

NO busques perfilesfuera de {SKILL_DIR}/profiles/; nunca accedas a los directorios de otras habilidades. Si se necesita un perfil en otro lugar, el usuario debe copiarlo explícitamente.

Orden de resolución:

1. Si el usuario ha ejecutado la skill con --user-company , utiliza ese slug.
2. De lo contrario, enumera los archivos profiles/*.json excluyendo example.json. Si existe exactamente un perfil, utilízalo (e indica al usuario cuál es). Si hay varios, pregunta al usuario (mediante chat sencillo) cuál desea.
3. Si no existe ningún perfil, muestra un mensaje de error claro e indica al usuario que cree uno (copiando profiles/example.json a profiles/.json y rellenándolo, o ejecutando la habilidad «company-research», que crea uno automáticamente).

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 se han encontrado perfiles en {SKILL_DIR}/profiles/. Copia el archivo profiles/example.json a profiles/.json y rellénalo, o ejecuta la habilidad «company-research» para crear uno."
    exit 1
  elif [ "$COUNT" -eq 1 ]; then
    USER_SLUG=$PROFILES
    echo "Se utiliza el único perfil disponible: ${USER_SLUG}"
  else
    echo "Se han encontrado varios perfiles:"
    echo "$PROFILES" | sed 's/^/  - /'
    echo "Vuelve a ejecutar con --user-company  para seleccionar uno."
    exit 1
  fi
fi

test -f {SKILL_DIR}/profiles/${USER_SLUG}.json || {
  echo "Perfil no encontrado: profiles/${USER_SLUG}.json"
  exit 1
}
cat {SKILL_DIR}/profiles/${USER_SLUG}.json

El perfil contiene: company, product, icp_description, existing_customers. Estos datos se incorporan tal cual en cada solicitud de los subagentes posteriores.

Paso 2: Reconocimiento

Detectar la plataforma de eventos y la estrategia de extracción. Un comando:

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

Escribe el archivo {OUTPUT_DIR}/recon.json con la plataforma, la estrategia y (para Next.js) nextDataPaths. Consulta references/event-platforms.md para ver el catálogo de plataformas y la prioridad de detección.

Resultados esperados:

• Clase Stripe Sessions (Next.js): platform: "next-data", 1-3 rutas
• Sessionize: plataforma: «sessionize»
• Lu.ma / Eventbrite: plataforma: «luma» | «eventbrite»
• Cualquier otra cosa: plataforma: «custom», estrategia: «markdown» (solución alternativa con el máximo esfuerzo)

Paso 3: Extraer personas

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

Lee el archivo recon.json, lo envía al extractor específico de la plataforma y genera los archivos people.jsonl (un ponente por línea) y seed_companies.txt (empresas sin duplicados).

El indicador --user-company también elimina de la lista de ponentes a los propios empleados de la organización anfitriona (un evento organizado por Stripe elimina a los empleados de Stripe) y a los propios empleados del usuario, ya que no son clientes potenciales.

Comprueba que la salida sea correcta:

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

Si people.jsonl está vacío o tiene menos de 10 líneas, significa que la herramienta de reconocimiento ha elegido una plataforma incorrecta; consulta references/event-platforms.md y vuelve a ejecutar la estrategia ajustada.

Paso 4: Agrupar por empresa

extract_event.mjs ya genera el archivo seed_companies.txt (una empresa por línea, sin duplicados y ordenado). Este paso es meramente informativo: comprueba que el recuento sea razonable antes de continuar:

wc -l {OUTPUT_DIR}/seed_companies.txt

Resultado esperado: aproximadamente entre 0,4 y 0,6 veces el número de ponentes (la mayoría de los eventos tienen una media de unos 2 ponentes por empresa; algunas empresas envían más de 5 y muchas envían solo 1).

Paso 5: Clasificación según el ICP

Proceso rápido: una llamada a la herramienta por empresa, sin investigación en profundidad. Asigna una puntuación a cada empresa de seed_companies.txt en función del ICP del usuario y escribe un breve esbozo de selección en companies/{slug}.md. Las empresas con icp_fit_score ≥ --icp-threshold (por defecto, 6) pasan a la investigación en profundidad del paso 7; el resto se quedan como esbozos de selección.

Patrón de distribución: dividir seed_companies.txt en lotes de ~10 y distribuir N subagentes en un ÚNICO lote de Agent (varias llamadas a la herramienta Agent en un solo mensaje). Cada subagente ejecuta el prompt de references/workflow.md → sección «ICP Triage». Límite máximo: 1 llamada a la herramienta por empresa (solo extract_page.mjs en la página de inicio), que se aplica mediante el patrón de comentario # browse call N/1.

# Crear archivos de lotes: cada línea del lote es «nombre|página-de-inicio-estimada|slug».
# extract_event.mjs solo emite NOMBRES de empresas (sin URL), por lo que creamos un slug y estimamos
# https://{slug-sin-espacios}.com como página de inicio canónica. El subagente de triaje
# puede escribir product_description: «Desconocido — contenido de la página de inicio inaccesible»
# y establecer la puntuación máxima en 3 si la URL estimada devuelve un error 404 — esa es la solución alternativa documentada en
# workflow.md (regla 3 de la indicación de triaje del ICP). Realizar una búsqueda real en la nube de navegación para
# descubrir la URL superaría el LÍMITE MÁXIMO DE UNA LLAMADA POR EMPRESA.
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");
'

# Dividir en lotes de unas 10 empresas
split -l 10 {OUTPUT_DIR}/_seed_with_urls.txt {OUTPUT_DIR}/_batch_triage_

# Contar lotes → número de subagentes que enviar (máximo de 6 por mensaje; segunda oleada para el resto)
ls {OUTPUT_DIR}/_batch_triage_* | wc -l

A continuación, en un único mensaje, envía una llamada a un agente por lote (hasta 6 en paralelo; oleadas posteriores una vez que la primera haya finalizado). Cada agente recibe la indicación de references/workflow.md → «ICP Triage» con estas sustituciones antes de enviarla:

• {SKILL_DIR} → ruta literal completa de la habilidad (p. ej., /Users/jay/skills/skills/event-prospecting)
• {OUTPUT_DIR} → ruta completa de salida
• {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION} → del perfil cargado
• {EVENT_NAME} → .title de recon.json
• {COMPANY_LIST} → contenido del archivo por lotes (p. ej., cat {OUTPUT_DIR}/_batch_triage_aa)
• {TOTAL} → número de líneas en este lote (sustituir en la llamada # browse por N/{TOTAL})

Envío del agente (esquema, repetir por lote en un solo mensaje):

Agente(
  descripción: «Lote de triaje ICP aa»,
  mensaje de solicitud: ,
  tipo de subagente: «uso general»
)
Agente(
  descripción: «Lote de clasificación de ICP ab»,
  mensaje de solicitud: ,
  tipo de subagente: «uso general»
)
... hasta 6 por mensaje

Una vez que todos los subagentes hayan devuelto resultados, comprueba que cada empresa de seed_companies.txt tenga un archivo correspondiente en companies/{slug}.md:

ls {OUTPUT_DIR}/companies/*.md | wc -l
# Debería ser igual a `wc -l {OUTPUT_DIR}/seed_companies.txt`

Elimina los archivos por lotes: rm {OUTPUT_DIR}/_batch_triage_*.

Paso 6: Filtrar por umbral de ICP

Lee el frontmatter de cada archivo companies/*.md y conserva aquellos con icp_fit_score >= 6 (o el valor que tenga el parámetro --icp-threshold ). Escribe los slugs de las empresas seleccionadas en {OUTPUT_DIR}/icp_fits.txt:

THRESHOLD=6   # del parámetro --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

Resultado esperado: entre el 20 % y el 40 % de seed_companies.txt. Si la tasa de supervivencia es inferior al 10 %, es posible que el umbral sea demasiado alto o que la descripción del ICP sea demasiado restrictiva; mostrar una advertencia al usuario.

Paso 7: Investigación en profundidad

Plan completo → Investigación → Síntesis solo sobre las empresas que se ajustan al ICP. Límite máximo: 5 consultas de herramientas por empresa (extracto de la página de inicio + 2-3 búsquedas de subpreguntas + 1-2 recuperaciones complementarias). Los subagentes SOBRESCRIBEN el esbozo de clasificación existente companies/{slug}.md con la versión más completa de la investigación en profundidad (frontmatter triage_only: false).

Patrón de envío: dividir icp_fits.txt en lotes de ~5 (por defecto en modo profundo) y distribuir un agente por lote en un ÚNICO mensaje (hasta 6 agentes por mensaje). Cada agente recibe la indicación de references/workflow.md → «Investigación en profundidad» con estas sustituciones:

• {SKILL_DIR}, {OUTPUT_DIR}, {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}
• {EVENT_NAME} (de recon.json .title), {EVENT_CONTEXT} (tema/tema, deducido manualmente a partir de la página de inicio del evento)
• {COMPANY_LIST} → contenido del archivo por lotes (cada línea: slug|sitio web)

# Crear pares {slug de empresa|sitio web} leyendo la información preliminar de cada esbozo de triaje
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

# Dividir en lotes de ~5 empresas (modo profundo)
split -l 5 {OUTPUT_DIR}/_deep_targets.txt {OUTPUT_DIR}/_batch_deep_
ls {OUTPUT_DIR}/_batch_deep_* | wc -l

Envío de agentes (esquema, repetir por lote en un solo mensaje):

Agente(
  descripción: «Lote de investigación en profundidad aa»,
  prompt: ,
  tipo_de_subagente: «uso general»
)
Agente(
  descripción: "Lote de investigación en profundidad ab",
  prompt: ,
  tipo_de_subagente: "uso general"
)
... hasta 6 por mensaje; segunda oleada tras el retorno de la primera

Una vez que todos los subagentes hayan devuelto un resultado, comprueba que los archivos de investigación en profundidad existen y que tienen triage_only: false:

grep -l "triage_only: false" {OUTPUT_DIR}/companies/*.md | wc -l
# Debería dar como resultado wc -l icp_fits.txt

Paso 8: Enriquecer a los ponentes

Por persona: recopilar la URL de LinkedIn, la actividad reciente (podcast / blog / charla / GitHub / X) y escribir people/{slug}.md. Límite máximo: 4 llamadas a herramientas por persona, tres vías:

1. búsqueda en la nube «{nombre} {empresa} linkedin» (siempre)
2. búsqueda en la nube «{nombre} podcast O charla O blog 2026» (profundidad+)
3. búsqueda en la nube «{nombre} github» (más profunda)
4. búsqueda en la nube «{nombre} site:x.com O site:twitter.com» (más profunda, en la medida de lo posible)

Modo rápido: omite el paso 8 por completo. Modo profundo: vías 1-2. Modo más profundo: vías 1-4.

Paso 8a — Preguntar al usuario: alcance del enriquecimiento

Antes de enviar la solicitud, calcula los recuentos de los dos candidatos y pide al usuario que elija. El valor por defecto es solo ajuste ICP (más rápido, más económico, lo que la mayoría de los usuarios quieren); el enriquecimiento de cada hablante es opcional, ya que el coste varía linealmente con el número de personas enriquecidas.

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

# Carriles por persona: 2 (profundidad) o 4 (más profunda) — coincide con {DEPTH}
LANES=2   # o 4 para mayor profundidad
echo "El ICP se ajusta a: ${ICP_FITS} ponentes × ${LANES} = $((ICP_FITS * LANES)) llamadas"
echo "Total:      ${TOTAL} ponentes × ${LANES} = $((TOTAL * LANES)) llamadas"

A continuación, pregunta mediante AskUserQuestion: una elección clara de dos opciones con el coste cuantificado de cada una:

AskUserQuestion(questions: [
  {
    question: "¿Qué ponentes se enriquecen?",
    header: "Ámbito de enriquecimiento",
    multiSelect: false,
    options: [
      { label: "Solo ICP FITS", description: "${ICP_FITS} altavoces, ~$((ICP_FITS * LANES)) llamadas (recomendado)" },
      { label: "Todos los altavoces", description: "${TOTAL} altavoces, ~$((TOTAL * LANES)) llamadas" }
    ]
  }
])

Guarda el ámbito elegido como ENRICH_SCOPE=icp_fits o ENRICH_SCOPE=all. Si el usuario selecciona «Todos los hablantes» y TOTAL × LANES > 600, muestra una advertencia y vuelve a preguntar: se trata de una ejecución de más de 10 minutos con cientos de llamadas a la herramienta.

Paso 8b — Filtrar y procesar por lotes

# Crea _people_to_enrich.jsonl en función de 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(`Enriqueciendo ${keep.length} de ${lines.length} ponentes`);
'
fi

# Dividir en lotes de ~5 personas
split -l 5 {OUTPUT_DIR}/_people_to_enrich.jsonl {OUTPUT_DIR}/_batch_people_

A continuación, en un único mensaje, envía una llamada de agente por lote (hasta 6 por mensaje) con la indicación de references/workflow.md → «Enriquecimiento de personas». La indicación de cada subagente debe incluir:

• {SKILL_DIR}, {OUTPUT_DIR}, {DEPTH} (deep | deeper)
• {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}
• {EVENT_NAME} (de recon.json .title)
• {LANES} → 2 para el modo «deep», 4 para el modo «deeper» (se sustituye en la llamada #browse N/{LANES})
• {PEOPLE_BATCH} → contenido de _batch_people_aa (cada línea es un registro JSON de people.jsonl)

Envío de agente (esquema, repetir por lote en un solo mensaje):

Agente(
  descripción: «Lote de enriquecimiento de personas aa»,
  mensaje: ,
  tipo_de_subagente: «uso general»
)
Agente(
  descripción: «Lote de enriquecimiento de personas ab»,
  solicitud: ,
  tipo_de_subagente: «uso general»
)
... hasta 6 por mensaje

Una vez que todos los subagentes hayan devuelto un resultado, comprueba que los archivos de personas existen:

ls {OUTPUT_DIR}/people/*.md | wc -l
# Debería ser igual a wc -l _people_to_enrich.jsonl

Paso 9: Compilar el informe

Genera el índice HTML agrupado por empresa, las vistas alternativas y el CSV con un solo comando:

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

Esto genera:

• {OUTPUT_DIR}/index.html — personas agrupadas por empresa, ordenadas según la puntuación ICP de la empresa (se abre en el navegador)
• {OUTPUT_DIR}/people.html — lista de ponentes filtrable (vista alternativa)
• {OUTPUT_DIR}/companies.html: tabla de empresas clasificadas según el ICP con los asistentes
• {OUTPUT_DIR}/results.csv — hoja de cálculo lista para llamadas en frío

A continuación, presenta un resumen en el chat:

## Prospección del evento completada — {Nombre del evento}

- **Total de ponentes extraídos**: {número}
- **Empresas únicas**: {número}
- **Empresas que se ajustan al ICP (puntuación ≥ {umbral})**: {número}
- **Ponentes con datos enriquecidos**: {número}
- **Distribución de puntuaciones** (empresas):
  - Coincidencia alta (8-10): {número}
  - Coincidencia parcial (5-7): {número}
  - Coincidencia débil (1-4): {número}
- **Informe abierto en el navegador**: {OUTPUT_DIR}/index.html

Mostrar las 5 primeras fichas de personas en una tabla Markdown ordenada por puntuación ICP de la empresa y, a continuación, ofrecer la opción de:

• Ajustar --icp-threshold y volver a ejecutar los pasos 6-9
• Exportar el CSV a un CRM