Prospection lors d'événements

À partir de l'URL d'une conférence → obtenez une liste classée des personnes avec lesquelles le commercial devrait prendre contact, accompagnée d'une justification « pourquoi les contacter » pour chacune d'entre elles.

Prérequis: la variable d’environnement BROWSERBASE_API_KEY et l’installation de la CLI browse (npm install -g browse). Utilisez browse cloud… pour les appels API et browse open / browse get markdown pour les pages de conférenciers riches en code JS.

Règles relatives aux chemins d’accès: utilisez toujours le chemin d’accès littéral complet dans toutes les commandes Bash — PAS ~ ni $HOME (ces deux éléments déclenchent des invites de validation de la « syntaxe d’expansion du shell »). Déterminez le répertoire de base une seule fois et utilisez-le partout. Lors de la création d’invites pour les sous-agents, remplacez {SKILL_DIR} par le chemin littéral complet (généralement /Users/jay/skills/skills/event-prospecting).

Répertoire de sortie: toutes les données issues de la prospection d’événements sont enregistrées dans ~/Desktop/{event_slug}_prospects_{AAAA-MM-JJ-HHMM}/. Le livrable final est le fichier index.html (personnes regroupées par entreprise, classées selon l’ICP de l’entreprise), avec les fichiers companies.html et people.html (filtrables) comme vues alternatives, ainsi que le fichier results.csv pour l’importation de prospects à froid.

IMPORTANT — Restrictions relatives à l’outil (s’appliquent à l’agent principal ET à tous les sous-agents):

• Toutes les recherches sur le Web : utilisez la recherche « Browse Cloud ». N’utilisez JAMAIS WebSearch.
• Toute extraction de contenu de page : utilisez le nœud {SKILL_DIR}/scripts/extract_page.mjs "". Ce script effectue la récupération via `browse cloud fetch --output`, analyse le titre, les balises meta et le corps du texte visible, et bascule automatiquement vers ` browse get markdown ` lorsque la récupération échoue ou renvoie un contenu allégé rendu par JavaScript. Ne créez JAMAIS manuellement un pipeline ` browse cloud fetch | sed`. N’utilisez JAMAIS WebFetch.
• Tous les résultats de recherche : les sous-agents rédigent un fichier Markdown par entreprise OU par personne dans {OUTPUT_DIR}/companies/{slug}.md ou {OUTPUT_DIR}/people/{slug}.md à l’aide de la syntaxe heredoc de bash. N’utilisez JAMAIS l’outil « Write » ni la commande python3 -c. Consultez references/example-research.md pour les deux formats de fichier.
• Compilation du rapport : utilisez la commande node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --open.
• Les sous-agents doivent utiliser UNIQUEMENT l’outil Bash. Aucun autre outil n’est autorisé.
• LIMITES STRICTES DE NOMBRE D’APPELS: triage ICP = 1 appel/entreprise ; recherche approfondie = 5 appels/entreprise ; enrichissement des données sur les personnes = 4 appels/personne. Consultez le fichier references/workflow.md pour plus de détails sur l’application de ces règles.

CRITIQUE — Règles anti-hallucination (s'appliquent à l'agent principal ET à tous les sous-agents):

• Ne déduisez JAMAIS la description du produit, le secteur d’activité ou la raison d’être d’une personne à partir des polices, du framework, du système de conception ou de la typographie d’un site. Ces éléments sont purement esthétiques et ne renseignent en rien sur ce que vend l’entreprise ou sur ce que fait la personne.
• NE JAMAIS laisser le profil ICP de l’utilisateur s’immiscer dans la description d’une cible. Si vous ne savez pas ce que fait la cible, écrivez « Inconnu » — ne la faites pas correspondre au profil ICP.
• La « description du produit » DOIT citer ou paraphraser une phrase spécifique issue de la sortie du fichier « extract_page.mjs ». Si aucun des éléments TITLE/META/OG/HEADINGS/BODY ne fournit de description de produit identifiable, écrivez « Inconnu » — contenu de la page d’accueil inaccessible — et limitez le score « icp_fit_score » à 3.
• Le « hook » d’une personne DOIT citer ou paraphraser un résultat spécifique issu d’ une recherche dans un « browse cloud » (titre de podcast, titre de blog, dépôt GitHub, résumé d’intervention). S’il n’existe aucun signal public au cours des 6 derniers mois, utilisez le contexte de l’événement (le titre de son intervention lors de cet événement).

CRITIQUE — Réduire au minimum les demandes d’autorisation:

• Les sous-agents DOIVENT regrouper TOUTES les écritures de fichiers en un SEUL appel Bash à l’aide de heredocs enchaînés. Un appel Bash = une demande d’autorisation.
• Regroupez TOUTES les recherches et TOUTES les récupérations dans des appels Bash uniques à l’aide du chaînage &&.

Présentation du pipeline

Suivez ces 10 étapes dans l’ordre. Ne sautez aucune étape et ne les réorganisez pas.

0. Configuration — répertoire de sortie + table rase
1. Chargement du profil — lire profiles/{user_slug}.json
2. Reconnaissance — détection de la plateforme d’événements
3. Extraction des personnes — people.jsonl
4. Regrouper par entreprise — seed_companies.txt
5. Triage ICP — notation rapide au niveau de l’entreprise (1 appel/entreprise)
6. Filtrage — entreprises dont le score icp_fit_score est supérieur ou égal à --icp-threshold
7. Recherche approfondie — cycle complet Planification → Recherche → Synthèse sur les correspondances ICP
8. Enrichir la liste des intervenants — demander à l’utilisateur : uniquement les profils adaptés à l’ICP (par défaut) ou tous les intervenants
9. Compiler le rapport — HTML + CSV, ouvrir dans le navigateur

L’utilisateur lance la compétence via une URL du type /event-prospecting . Analysez EVENT_URL à partir de ce message d’appel. Valeurs par défaut : DEPTH=deep, ICP_THRESHOLD=6. L’USER_SLUG (profil ICP) est déterminé automatiquement à l’étape 1 à partir des fichiers de profil existant localement — il n’y a pas de profil par défaut intégré. Ne demandez PAS à l’utilisateur de confirmer l’URL — il vous l’a déjà fournie.

Étape 0 : Configuration du répertoire de sortie

Déterminez le répertoire de sortie à partir de l’URL que l’utilisateur vous a fournie. Ne codez PAS en dur le nom d’un événement.

# EVENT_URL provient du message d’invocation (ce que l’utilisateur a saisi après `/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"

Utilisez le chemin d'accès complet littéral — jamais ~ ou $HOME. Transmettez {OUTPUT_DIR} en tant que chemin d'accès complet littéral à toutes les invites des sous-agents.

Étape 1 : Charger le profil utilisateur

Le profil définit l’ICP sur lequel se basent le triage ICP et la recherche approfondie. Chargez-le à partir de {SKILL_DIR}/profiles/{user_slug}.json (interchangeable entre toutes les compétences GTM — même structure que la recherche sur les entreprises). example.json est un modèle, pas un vrai profil — ne l’utilisez jamais.

NE CHERCHEZ PAS de profilsen dehors de {SKILL_DIR}/profiles/ — n’accédez jamais aux répertoires d’autres compétences. Si un profil est nécessaire ailleurs, l’utilisateur doit le copier explicitement.

Ordre de résolution:

1. Si l’utilisateur a lancé la commande avec l’option --user-company , utilisez ce slug.
2. Sinon, répertoriez les fichiers profiles/*.json en excluant example.json. S’il n’existe qu’un seul profil, utilisez-le (et indiquez à l’utilisateur de quel profil il s’agit). S’il en existe plusieurs, demandez à l’utilisateur (via un chat simple) lequel il souhaite utiliser.
3. S’il n’existe aucun profil, signaler clairement l’échec et inviter l’utilisateur à en créer un (en copiant profiles/example.json vers profiles/.json et en le complétant, ou en exécutant la compétence « company-research » qui en crée un automatiquement).

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 "Aucun profil trouvé dans {SKILL_DIR}/profiles/. Copiez le fichier profiles/example.json dans le répertoire profiles/.json et complétez-le, ou exécutez la compétence « company-research » pour en créer un."
    exit 1
  elif [ "$COUNT" -eq 1 ]; then
    USER_SLUG=$PROFILES
    echo "Utilisation du seul profil disponible : ${USER_SLUG}"
  else
    echo "Plusieurs profils trouvés :"
    echo "$PROFILES" | sed 's/^/  - /'
    echo « Relancez la commande avec --user-company  pour en choisir un. »
    exit 1
  fi
fi

test -f {SKILL_DIR}/profiles/${USER_SLUG}.json || {
  echo "Profil introuvable : profiles/${USER_SLUG}.json"
  exit 1
}
cat {SKILL_DIR}/profiles/${USER_SLUG}.json

Le profil contient les champs suivants : company, product, icp_description, existing_customers. Ceux-ci sont intégrés tels quels dans chaque invite des sous-agents en aval.

Étape 2 : Reconnaissance

Détecter la plateforme d’événements et la stratégie d’extraction. Une seule commande :

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

Écrit le fichier {OUTPUT_DIR}/recon.json contenant la plateforme, la stratégie et (pour Next.js) nextDataPaths. Consultez le fichier references/event-platforms.md pour le catalogue des plateformes et la priorité de détection.

Résultats attendus :

• Classe Stripe Sessions (Next.js) : platform: "next-data", 1 à 3 chemins
• Sessionize : plateforme : « sessionize »
• Lu.ma / Eventbrite : platform: "luma" | "eventbrite"
• Tout autre cas : platform: "custom", strategy: "markdown" (solution de secours au mieux)

Étape 3 : extraction des personnes

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

Lit le fichier recon.json, transmet les données à l’extracteur spécifique à la plateforme, écrit le fichier people.jsonl (un intervenant par ligne) et le fichier seed_companies.txt (entreprises dédupliquées).

L'option --user-company exclut également de la liste des intervenants les employés de l'organisation hôte (un événement hébergé par Stripe exclut les employés de Stripe) et les employés de l'utilisateur lui-même — ceux-ci ne sont pas des prospects.

Vérifiez la validité de la sortie :

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

Si le fichier people.jsonl est vide ou comporte moins de 10 lignes, cela signifie que le système de reconnaissance a sélectionné la mauvaise plateforme — consultez le fichier references/event-platforms.md et relancez l’opération avec une stratégie adaptée.

Étape 4 : Regrouper par entreprise

extract_event.mjs génère déjà le fichier seed_companies.txt (une entreprise par ligne, sans doublons, trié). Cette étape est purement informative — vérifiez que le nombre semble raisonnable avant de passer à l’étape suivante :

wc -l {OUTPUT_DIR}/seed_companies.txt

Résultat attendu : environ 0,4 à 0,6 fois le nombre d’intervenants (la plupart des événements comptent en moyenne environ 2 intervenants par entreprise ; certaines entreprises en envoient plus de 5, tandis que beaucoup n’en envoient qu’un).

Étape 5 : Triage ICP

Triage rapide — un appel d’outil par entreprise, sans recherche approfondie. Attribuez un score à chaque entreprise du fichier seed_companies.txt par rapport à l’ICP de l’utilisateur et rédigez une brève note de triage dans le fichier companies/{slug}.md. Les entreprises dont le score icp_fit_score est supérieur ou égal à --icp-threshold (valeur par défaut : 6) passent à l’étape 7 (recherche approfondie) ; les autres restent sous forme de brouillons de triage.

Modèle de répartition: diviser le fichier seed_companies.txt en lots d’environ 10 et répartir N sous-agents dans un SEUL lot d’Agent (plusieurs appels d’outils Agent dans un seul message). Chaque sous-agent exécute la prompt issue du fichier references/workflow.md → section « ICP Triage ». Limite stricte : 1 appel d’outil par entreprise (uniquement extract_page.mjs sur la page d’accueil), appliquée via le modèle de commentaire # browse call N/1.

# Création des fichiers de lots : chaque ligne de lot est au format « nom|page_d’accueil_devinee|slug ».
# extract_event.mjs ne renvoie que les NOMS d’entreprises (pas d’URL), nous générons donc un slug et devinons
# https://{slug-sans-espaces}.com comme page d’accueil canonique. Le sous-agent de triage
# est autorisé à écrire product_description : « Inconnu — contenu de la page d’accueil inaccessible »
# et à fixer le score à 3 si l’URL devinée renvoie une erreur 404 — c’est la solution de secours documentée dans
# workflow.md (règle n° 3 de l’invite de triage ICP). Lancer une véritable recherche dans le nuage de navigation pour
# découvrir l’URL ferait sauter la LIMITE STRICTE d’un appel par entreprise.
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");
'

# Répartition en lots d’environ 10 entreprises
split -l 10 {OUTPUT_DIR}/_seed_with_urls.txt {OUTPUT_DIR}/_batch_triage_

# Compter les lots → nombre de sous-agents à envoyer (plafonné à 6 par message ; deuxième vague pour le reste)
ls {OUTPUT_DIR}/_batch_triage_* | wc -l

Puis, dans un seul message, envoyer un appel d’agent par lot (jusqu’à 6 en parallèle ; vagues suivantes après le retour de la première). Chaque agent reçoit l’invite de references/workflow.md → « ICP Triage » avec ces substitutions avant l’envoi :

• {SKILL_DIR} → chemin littéral complet de la compétence (par ex. /Users/jay/skills/skills/event-prospecting)
• {OUTPUT_DIR} → chemin littéral complet de la sortie
• {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION} → à partir du profil chargé
• {EVENT_NAME} → .title du fichier recon.json
• {COMPANY_LIST} → contenu du fichier batch (par ex. cat {OUTPUT_DIR}/_batch_triage_aa)
• {TOTAL} → nombre de lignes dans ce lot (à substituer dans l’appel # browse N/{TOTAL})

Envoi de l'agent (squelette, à répéter pour chaque lot dans un seul message):

Agent(
  description : « ICP triage lot aa »,
  prompt : ,
  subagent_type : « general-purpose »
)
Agent(
  description : « Triage ICP lot ab »,
  invite : ,
  type_de_sous-agent : « usage général »
)
... jusqu'à 6 par message

Une fois que tous les sous-agents ont renvoyé leur résultat, vérifiez que chaque entreprise de seed_companies.txt dispose d’un fichier correspondant companies/{slug}.md:

ls {OUTPUT_DIR}/companies/*.md | wc -l
# Doit être égal à `wc -l {OUTPUT_DIR}/seed_companies.txt`

Nettoyez les fichiers batch : rm {OUTPUT_DIR}/_batch_triage_*.

Étape 6 : Filtrer selon le seuil ICP

Lire les métadonnées de chaque fichier companies/*.md, ne conserver que ceux dont icp_fit_score est >= 6 (ou quelle que soit la valeur de --icp-threshold ). Écrire les slugs des entreprises retenues dans {OUTPUT_DIR}/icp_fits.txt:

THRESHOLD=6   # issu de l’option --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

Résultat attendu : 20 à 40 % du fichier seed_companies.txt. Si le taux de survie est inférieur à 10 %, le seuil est peut-être trop élevé ou la description de l’ICP trop restrictive — afficher un avertissement à l’utilisateur.

Étape 7 : Recherche approfondie

Plan complet → Recherche → Synthèse portant uniquement sur les entreprises correspondant à l’ICP. Limite stricte : 5 appels d’outils par entreprise (extrait de la page d’accueil + 2 à 3 recherches par sous-question + 1 à 2 récupérations supplémentaires). Les sous-agents REMPLACENT l’ébauche de triage existante companies/{slug}.md par la version enrichie issue de la recherche approfondie (frontmatter triage_only : false).

Modèle de distribution: diviser le fichier icp_fits.txt en lots d’environ 5 (mode approfondi par défaut) et répartir un agent par lot dans un SEUL message (jusqu’à 6 agents par message). Chaque agent reçoit la consigne issue du fichier references/workflow.md → « Recherche approfondie » avec les substitutions suivantes :

• {SKILL_DIR}, {OUTPUT_DIR}, {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}
• {EVENT_NAME} (à partir de .title dans recon.json ), {EVENT_CONTEXT} (thème / sujet, déduit manuellement à partir de la page d’accueil de l’événement)
• {COMPANY_LIST} → contenu du fichier batch (chaque ligne slug|site web)

# Créer des paires {slug-entreprise|site-web} en lisant les métadonnées de chaque ébauche de 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

# Division en lots d’environ 5 entreprises (mode approfondi)
split -l 5 {OUTPUT_DIR}/_deep_targets.txt {OUTPUT_DIR}/_batch_deep_
ls {OUTPUT_DIR}/_batch_deep_* | wc -l

Déploiement des agents (squelette, à répéter pour chaque lot dans un seul message):

Agent(
  description : "Lot de recherche approfondie aa",
  prompt : ,
  subagent_type : "usage général"
)
Agent(
  description : "Lot de recherche approfondie ab",
  invite : ,
  type_de_sous-agent : "usage général"
)
... jusqu’à 6 par message ; deuxième vague après le retour de la première

Une fois que tous les sous-agents ont renvoyé leur résultat, vérifiez que les fichiers de recherche approfondie existent et que la valeur triage_only: false est présente :

grep -l "triage_only: false" {OUTPUT_DIR}/companies/*.md | wc -l
# Doit donner le même résultat que wc -l icp_fits.txt

Étape 8 : Enrichir les intervenants

Par personne : récupérer l’URL LinkedIn, l’activité récente (podcast / blog / conférence / GitHub / X), et créer le fichier people/{slug}.md. Limite stricte : 4 appels d’outils par personne, trois voies :

1. recherche dans le cloud « {nom} {entreprise} linkedin » (toujours)
2. recherche dans le cloud « {nom} podcast OU conférence OU blog 2026 » (approfondie+)
3. recherche dans le cloud « {nom} github » (plus approfondie)
4. recherche dans le nuage « {nom} site:x.com OU site:twitter.com » (plus approfondie, au mieux)

Mode rapide : ignorer complètement l’étape 8. Mode approfondi : voies 1 et 2. Mode plus approfondi : voies 1 à 4.

Étape 8a — Demander à l’utilisateur : portée de l’enrichissement

Avant l’envoi, calculez le nombre de candidats pour chaque option et demandez à l’utilisateur de choisir. Par défaut, seule l’adaptation ICP est utilisée (plus rapide, moins coûteuse, ce que la plupart des utilisateurs souhaitent) ; l’enrichissement de chaque intervenant est facultatif, car le coût augmente linéairement avec le nombre de personnes enrichies.

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

# Nombre de voies par personne : 2 (profond) ou 4 (plus profond) — correspond à {DEPTH}
LANES=2   # ou 4 pour plus de profondeur
echo "Correspondances ICP : ${ICP_FITS} intervenants × ${LANES} = $((ICP_FITS * LANES)) appels"
echo "Total :      ${TOTAL} intervenants × ${LANES} = $((TOTAL * LANES)) appels"

Puis poser la question via AskUserQuestion — choix clair à deux options avec le coût quantifié pour chacune :

AskUserQuestion(questions: [
  {
    question: "Quels locuteurs enrichir ?",
    header: "Portée de l’enrichissement",
    multiSelect: false,
    options: [
      { label: "ICP FITS uniquement", description: "${ICP_FITS} haut-parleurs, environ $((ICP_FITS * LANES)) appels (recommandé)" },
      { label: "Tous les locuteurs", description: "${TOTAL} locuteurs, environ $((TOTAL * LANES)) appels" }
    ]
  }
])

Enregistrez la portée choisie sous ENRICH_SCOPE=icp_fits ou ENRICH_SCOPE=all. Si l’utilisateur choisit « Tous les locuteurs » et que TOTAL × LANES > 600, affichez un avertissement et demandez-lui de confirmer — cela correspond à une exécution de plus de 10 minutes avec des centaines d’appels à l’outil.

Étape 8b — Filtrage et traitement par lots

# Créer le fichier _people_to_enrich.jsonl en fonction 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(`Enrichissement de ${keep.length} intervenants sur ${lines.length}`);
'
fi

# Répartition en lots d’environ 5 personnes
split -l 5 {OUTPUT_DIR}/_people_to_enrich.jsonl {OUTPUT_DIR}/_batch_people_

Ensuite, dans un seul message, envoyez un appel d’agent par lot (jusqu’à 6 par message) avec l’invite tirée de references/workflow.md → « Person Enrichment ». L’invite de chaque sous-agent doit inclure :

• {SKILL_DIR}, {OUTPUT_DIR}, {DEPTH} (deep | deeper)
• {USER_COMPANY}, {USER_PRODUCT}, {ICP_DESCRIPTION}
• {EVENT_NAME} (à partir de recon.json .title)
• {LANES} → 2 pour le mode « deep », 4 pour le mode « deeper » (à insérer dans l’appel # browse N/{LANES})
• {PEOPLE_BATCH} → contenu de _batch_people_aa (chaque ligne correspondant à un enregistrement JSON issu de people.jsonl)

Envoi d’agents (squelette, à répéter pour chaque lot dans un seul message):

Agent(
  description : « Lot d’enrichissement des données personnelles aa »,
  prompt : ,
  subagent_type : « usage général »
)
Agent(
  description : « Lot d’enrichissement des données sur les personnes ab »,
  prompt : ,
  subagent_type : « general-purpose »
)
... jusqu’à 6 par message

Une fois que tous les sous-agents ont renvoyé leur résultat, vérifiez que les fichiers relatifs aux personnes existent :

ls {OUTPUT_DIR}/people/*.md | wc -l
# Doit être égal à wc -l _people_to_enrich.jsonl

Étape 9 : Compiler le rapport

Générez l’index HTML regroupé par entreprise, les vues alternatives et le fichier CSV en une seule commande :

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

Cela génère :

• {OUTPUT_DIR}/index.html — personnes regroupées par entreprise, classées selon le score ICP de l’entreprise (s’ouvre dans le navigateur)
• {OUTPUT_DIR}/people.html — liste des intervenants filtrable (vue alternative)
• {OUTPUT_DIR}/companies.html — tableau des entreprises classées selon l’ICP, avec les participants
• {OUTPUT_DIR}/results.csv — feuille de calcul prête à l’emploi pour la prospection à froid

Présentez ensuite un résumé dans le chat :

## Prospection de l’événement terminée — {Nom de l’événement}

- **Nombre total d’intervenants extraits** : {nombre}
- **Entreprises uniques** : {nombre}
- **Adéquation ICP (score ≥ {seuil})** : {nombre}
- **Intervenants enrichis** : {nombre}
- **Répartition des scores** (entreprises) :
  - Adéquation forte (8-10) : {nombre}
  - Adéquation partielle (5-7) : {nombre}
  - Adéquation faible (1-4) : {nombre}
- **Rapport ouvert dans le navigateur** : {OUTPUT_DIR}/index.html

Afficher les 5 premières fiches de personnes sous forme de tableau Markdown trié par score ICP de l’entreprise, puis proposer de :

• Ajuster --icp-threshold et relancer les étapes 6 à 9
• Exporter le fichier CSV vers un CRM