Construisez une liste de prospects scorée en quelques minutes — déposez 50 comptes, récupérez recherche + CSV — Claude Skill

Exemple de fichier de recherche entreprise

Chaque sous-agent de recherche écrit un fichier markdown par entreprise dans {OUTPUT_DIR}/{company-slug}.md, où {OUTPUT_DIR} est le répertoire Desktop propre à l'exécution, configuré par l'agent principal à l'Étape 0 (par exemple ~/Desktop/acme_research_2026-04-23/). Le frontmatter YAML contient les champs structurés pour la compilation du rapport + CSV. Le corps contient la recherche lisible par un humain.

Template

---
company_name: Acme Inc
website: https://acme.com
product_description: Gestion d'inventaire propulsée par l'IA pour marques e-commerce
industry: E-commerce / SaaS
target_audience: Marques e-commerce mid-market
key_features: prévision de demande | réapprovisionnement automatisé | synchronisation multi-entrepôts
icp_fit_score: 8
icp_fit_reasoning: SaaS e-commerce Series A, utilise Selenium pour le scraping, expansion vers l'UE — fort fit
employee_estimate: 50-100
funding_info: Series A, $12M
headquarters: San Francisco, CA
---

## Produit
Gestion d'inventaire propulsée par l'IA pour marques e-commerce. Aide les marques DTC
à automatiser le réapprovisionnement et à synchroniser plusieurs entrepôts.

## Observations de recherche
- **[high]** Optimisation checkout pour boutiques Shopify, au service de marques DTC mid-market avec $5M-$50M de revenu (source : acme.com/about)
- **[high]** Series A, $12M levés au T3 2025 auprès de Sequoia (source : TechCrunch)
- **[medium]** A récemment recruté 3 data engineers, expansion de l'équipe plateforme (source : offres d'emploi LinkedIn)
- **[medium]** Utilise Selenium pour le web scraping dans son pipeline de données (source : page carrières)

Règles des champs

• Frontmatter YAML : tous les champs structurés vont ici. Ils sont extraits pour la compilation CSV.
• key_features : liste séparée par des pipes (|) dans le YAML, pas un tableau JSON.
• icp_fit_score : entier de 1 à 10.
• icp_fit_reasoning : une ligne, référence des observations spécifiques.
• Sections du corps : ## Product, ## Research Findings.
• Format des observations : - **[confidence]** fact (source: url or description)
• Nom de fichier : {OUTPUT_DIR}/{company-slug}.md, avec un slug en minuscules et traits d'union (par exemple acme-inc.md).
• Déduplication : un fichier par entreprise. Si un sous-agent rencontre une entreprise qui a déjà un fichier, écraser avec des données plus riches.

Écriture via heredoc Bash

Les sous-agents écrivent ces fichiers avec un heredoc bash pour éviter les prompts de sécurité. Utilisez le chemin littéral complet {OUTPUT_DIR} — pas ~ ni $HOME :

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

## Product
...

## Research Findings
...
COMPANY_MD

Utilisez 'COMPANY_MD' (avec guillemets) comme délimiteur pour empêcher l'expansion des variables shell.

IMPORTANT : écrire TOUS les fichiers entreprise dans UN SEUL appel Bash avec des heredocs chaînés pour minimiser les prompts d'autorisation.

Recherche d'entreprises — patterns de recherche approfondie

Vue d'ensemble

Cette référence définit deux contextes de recherche :

1. Self-Research (Étape 1) — recherche approfondie sur l'entreprise de l'utilisateur pour construire une base ICP solide
2. Target Research (Étape 6) — recherche sur chaque entreprise découverte avec Plan→Research→Synthesize

Les deux utilisent le même pattern en 3 phases, mais avec des sous-questions et objectifs différents.

Self-Research (entreprise de l'utilisateur)

C'est la recherche la plus importante du portefeuille commercial. Toutes les décisions aval en dépendent.

Sous-questions

• "Que vend {company} et quel problème spécifique résout-elle ?"
• "Qui sont les clients existants de {company} ? Quelles industries, tailles d'entreprise et cas d'usage ?"
• "Qui sont les concurrents de {company} et qu'est-ce qui les différencie ?"
• "Quel modèle de pricing {company} utilise-t-elle et quel est le persona acheteur typique ?"
• "Quels cas d'usage et points de douleur le marketing de {company} met-il en avant ?"

Découverte de pages

Découvrez les pages du site dynamiquement — ne PAS coder en dur des chemins comme /about ou /customers :

1. Fetch browse cloud fetch --allow-redirects "{company website}/sitemap.xml" — source principale, contient TOUTES les pages
2. Scanner les URL du sitemap avec les mots-clés : customer, case-stud, pricing, about, use-case, blog, docs, industry, solution
3. Optionnellement fetcher browse cloud fetch --allow-redirects "{company website}/llms.txt" pour les descriptions de pages
4. Choisir les 3 à 5 URL les plus pertinentes dans le sitemap et les fetcher
5. Le sitemap est la source de vérité. llms.txt est un contexte bonus, mais souvent incomplet.

Recherche externe

• Recherche : "{company} customers use cases reviews"
• Recherche : "{company} alternatives competitors vs"
• Fetcher 1 à 2 résultats tiers parmi les plus informatifs (G2, articles de blog, comparaisons)

Sortie de synthèse

À partir de toutes les observations, produire un profil d'entreprise :

• Entreprise : nom
• Produit : ce qu'elle vend, comment cela fonctionne, capacités clés (2 à 3 phrases, spécifiques)
• Clients existants : clients nommés ou types de clients trouvés
• Concurrents : avec qui elle est en concurrence, différenciateurs clés
• Cas d'usage : large liste de cas d'usage servis par le produit (PAS attachée à une seule verticale)

Ne PAS inclure l'ICP, l'angle de pitch ni les sous-verticales dans le profil. Ce sont des décisions de ciblage propres à chaque exécution, prises à l'Étape 2 après confirmation du profil. Le profil est une fiche factuelle générale réutilisable, quelle que soit la verticale ciblée ensuite.

Pourquoi c'est important

Un profil superficiel produit des requêtes génériques, un scoring de leads faible et des emails standardisés. Un profil riche avec clients, concurrents et cas d'usage spécifiques produit des requêtes ciblées, un scoring précis et des emails qui référencent de vrais points de douleur.

Recherche sur une entreprise cible (Étape 6)

Templates de sous-questions

Générez les sous-questions depuis ces catégories selon l'ICP et les champs d'enrichissement demandés. Toutes les catégories ne s'appliquent pas à chaque entreprise — choisissez les plus pertinentes.

Priorité 1 (toujours demander)

• Produit/Marché : "Que vend {company} et qui sont ses clients ?"
• Fit ICP : "Comment le produit/marché de {company} se rapporte-t-il à {sender's ICP description} ?"

Priorité 2 (demander en deep/deeper)

• pile technique : "Quelles technologies, frameworks ou infrastructures {company} utilise-t-elle ?"
• Signaux de croissance : "{company} a-t-elle levé des fonds, lancé des produits ou récemment étendu son activité ?"
• Points de douleur : "Quels défis {company} peut-elle rencontrer que {sender's product} adresse ?"

Priorité 3 (demander seulement en deeper)

• Décideurs : "Qui dirige l'ingénierie, le produit ou la croissance chez {company} ?"
• Paysage concurrentiel : "Qui sont les concurrents de {company} et comment se différencient-ils ?"
• Clients/Case studies : "Qui sont les clients notables de {company} et quels résultats met-elle en avant ?"

Patterns de requêtes de recherche

Pour chaque sous-question, générer 2 à 3 variantes de requête :

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

# Tech outils
"{company name} tech outils engineering blog"
"{company name} careers software engineer" (les offres d'emploi révèlent la outils)

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

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

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

Format des observations

Chaque observation est une déclaration factuelle autonome liée à une source :

{
  "subQuestion": "What does Acme sell and who are their customers?",
  "fact": "Acme fournit de l'optimisation checkout pour boutiques Shopify, au service de marques DTC mid-market avec $5M-$50M de revenu",
  "sourceUrl": "https://acme.com/about",
  "sourceTitle": "About Acme - Checkout Optimization",
  "confidence": "high"
}

Niveaux de confiance :

• high : indiqué directement sur le site de l'entreprise ou dans une communication officielle
• medium : inféré depuis des offres d'emploi, articles tiers ou signaux indirects
• low : spéculatif selon l'industrie/catégorie, ou provenant de sources obsolètes

Règles de boucle de recherche

1. Traiter les sous-questions par priorité — Priorité 1 d'abord, puis 2, puis 3
2. 3 à 5 observations par sous-question, puis passer à la suite — ne pas épuiser un sujet
3. Utiliser des appels outil parallèles — rechercher plusieurs requêtes simultanément quand c'est possible
4. Reformuler, ne pas réessayer à l'identique — si une recherche renvoie de mauvais résultats, essayer d'autres mots-clés
5. Fetcher sélectivement — ne pas fetcher chaque URL des résultats. Choisir les 1 à 2 plus pertinentes selon le titre et l'URL
6. S'arrêter à la limite d'étapes — respecter le budget d'étapes du mode de profondeur par entreprise
7. Homepage d'abord — toujours fetcher la homepage de l'entreprise avant de passer à d'autres pages
8. Dédupliquer les observations — ne pas enregistrer deux fois le même fait depuis des sources différentes

Comportement par mode de profondeur

Mode Quick (100+ leads)

• Sauter la Phase A — pas de décomposition en sous-questions
• Phase B : fetcher la homepage de l'entreprise. Lancer 1 à 2 recherches complémentaires si les données homepage sont minces.
• Phase C : extraire les données disponibles, scorer l'ICP, rédiger l'email à partir de ce qui est disponible
• Budget : 2 à 3 appels outil au total par entreprise
• Trade-off : rapide et peu coûteux, mais les emails peuvent être moins personnalisés

Mode Deep (25-50 leads)

• Phase A : décomposer en 2 à 3 sous-questions (Priorité 1 + Priorité 2 sélectionnée)
• Phase B : pour chaque sous-question, lancer 2 à 3 recherches + fetcher 1 à 2 URL. Viser 3 à 5 observations par sous-question.
• Phase C : synthétiser depuis toutes les observations. Le raisonnement ICP référence des preuves spécifiques. L'email utilise l'observation la plus spécifique/convaincante.
• Budget : 5 à 8 appels outil au total par entreprise
• Trade-off : bon équilibre entre profondeur et volume

Mode Deeper (10-25 leads)

• Phase A : décomposer en 4 à 5 sous-questions (Priorité 1 + 2 + Priorité 3 sélectionnée)
• Phase B : rechercher exhaustivement. Fetcher plusieurs pages par entreprise (homepage, about, blog, careers, pages produit). Viser 3 à 5 observations par sous-question.
• Phase C : synthétiser avec preuves citées. Le raisonnement ICP est détaillé. L'email référence plusieurs signaux spécifiques.
• Budget : 10 à 15 appels outil au total par entreprise
• Trade-off : intelligence de haute qualité, mais lente et coûteuse

Instructions de synthèse

Après la boucle de recherche pour une entreprise, synthétiser les observations dans l'enregistrement de sortie :

Scoring ICP

Scorer de 1 à 10 avec TOUTES les observations accumulées comme preuves :

• 8-10 : forte correspondance. Plusieurs observations à haute confiance confirment la bonne industrie, le bon stade d'entreprise et un alignement clair avec le point de douleur. L'angle de pitch répond directement à un besoin visible étayé par des preuves.
• 5-7 : correspondance partielle. Certaines observations suggèrent une pertinence, mais des signaux clés manquent ou sont à faible confiance. Industrie adjacente ou point de douleur peu clair.
• 1-4 : faible correspondance. Les observations indiquent un mauvais segment, une taille trop grande/petite ou aucun lien apparent avec le produit de l'expéditeur.

Rédiger icp_fit_reasoning en référençant des observations spécifiques : "Series A fintech (depuis Crunchbase), utilise Selenium pour le scraping (depuis une offre d'emploi), expansion vers le marché UE (depuis le blog) — fort fit pour l'infrastructure navigateur."

Personnalisation d'email

Utiliser les observations les plus riches et spécifiques pour le contexte email :

• Ouverture : utiliser l'observation la plus concrète (fonctionnalité produit spécifique, lancement récent, offre d'emploi)
• Pont : connecter une observation sur leurs défis/outils à l'angle de pitch de l'expéditeur
• Si seules des observations à faible confiance existent, garder l'email plus court et plus général — ne pas inventer de spécificité

Champs d'enrichissement

Mapper les observations vers les champs d'enrichissement :

• product_description → depuis les observations Produit/Marché
• industry → inféré depuis Produit/Marché
• employee_estimate → depuis la recherche LinkedIn ou les observations de page carrières
• funding_info → depuis les observations Signaux de croissance
• headquarters → depuis la homepage ou la page about de l'entreprise
• target_audience → depuis les observations Produit/Marché
• key_features → depuis les observations de page produit

Si un champ n'a pas d'observation de support, le laisser vide plutôt que deviner.

Règles anti-hallucination

Appliquer ces règles au moment de la synthèse. Elles existent parce que le mode d'échec — surtout sur les landing pages Framer/Next.js avec peu de texte rendu serveur — consiste pour le sous-agent à calquer des indices visuels sur l'ICP de l'expéditeur et fabriquer une description plausible :

1. La typographie n'est pas un produit. Ne jamais inférer product_description, industry ou target_audience depuis les polices, le design system, le choix de framework (Framer, Next.js, React) ou le niveau de finition du site. "Construit avec Framer" et "utilise Geist Mono" sont des observations d'outillage, pas des signaux de ce que l'entreprise vend.
2. Pas de fuite d'ICP. Si la homepage est mince et que la recherche externe ne donne rien, NE PAS orienter par défaut la description de la cible vers l'ICP de l'expéditeur. Manufacturing AI ≠ browser automation simplement parce que les deux utilisent l'IA.
3. Citer, pas paraphraser de mémoire. product_description doit citer ou paraphraser de près une phrase spécifique issue de la sortie extract_page.mjs (TITLE / META_DESCRIPTION / OG_DESCRIPTION / HEADINGS / BODY) ou d'un résultat de recherche externe. Si aucune phrase de ce type n'existe, écrire Unknown — homepage content not accessible.
4. Plafonner les scores sur preuve mince. Si product_description vaut Unknown, fixer icp_fit_score ≤ 3 et icp_fit_reasoning: Insufficient evidence — homepage returned no readable content. Ne pas justifier un score plus élevé uniquement avec des signaux inférés.

Recherche d'entreprises — référence de workflow

Schéma JSON des batchs de découverte

Fichier : /tmp/company_discovery_batch_{N}.json

browse cloud search --output écrit un objet JSON (PAS un tableau plat) :

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

Le script list_urls.mjs gère les deux formats (tableau plat et { results: [...] }).

Format markdown de recherche entreprise

Fichier : {OUTPUT_DIR}/{company-slug}.md

Où {OUTPUT_DIR} est le répertoire propre à l'exécution sur le Desktop de l'utilisateur (par exemple ~/Desktop/acme_research_2026-04-23/). L'agent principal le configure à l'Étape 0 et transmet le chemin littéral complet à chaque sous-agent.

Chaque sous-agent de recherche écrit un fichier markdown par entreprise. Voir references/example-research.md pour le template complet.

Champs du frontmatter YAML (utilisés pour la compilation rapport + CSV) :

• company_name (requis)
• website (requis)
• product_description
• industry
• target_audience
• key_features (séparé par pipes : feature1 | feature2 | feature3)
• icp_fit_score (entier 1-10, requis)
• icp_fit_reasoning
• employee_estimate
• funding_info
• headquarters

Sections du corps :

• ## Product — ce que l'entreprise fait
• ## Research Findings — preuves avec niveaux de confiance et sources

CRITIQUE : utilisez des noms de champs cohérents dans tous les fichiers. Le script compile_report.mjs lit ces champs.

Extraction du contenu de page

Utilisez extract_page.mjs pour toute extraction de contenu homepage/page produit. Il fetch via browse cloud fetch --output, parse titre + meta + texte visible du body, et bascule automatiquement vers browse get markdown quand le fetch échoue ou renvoie un contenu mince rendu en JS :

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

La sortie est un bloc structuré :

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

Pourquoi pas un portefeuille commercial brut browse cloud fetch | sed ? Sans --output, browse cloud fetch renvoie une enveloppe JSON avec le HTML intégré comme chaîne échappée. Un portefeuille commercial sed naïf supprime les <> du wrapper et du contenu, ainsi que les balises <meta>, qui sur les SPA Framer/Next.js sont souvent le seul contenu lisible. extract_page.mjs utilise --output pour parser directement le HTML brut.

Quand utiliser browse cloud fetch brut : seulement pour les petits fichiers structurés où vous voulez garder l'enveloppe JSON intacte — par exemple sitemap.xml, robots.txt, llms.txt. Pour toute page HTML destinée à un modèle, utilisez extract_page.mjs.

Vérifier que le contenu est réel (pas halluciné)

Avant d'écrire product_description, industry ou target_audience dans un fichier entreprise, confirmez que l'assertion est fondée sur la sortie extract_page.mjs. Citez ou paraphrasez de près TITLE, META_DESCRIPTION, OG_DESCRIPTION, HEADINGS ou BODY.

Si extract_page.mjs renvoie FETCH_OK: false ET FALLBACK_TO_BROWSE: false (ou BODY_CHARS < 50), la homepage est inaccessible. N'inventez pas. Écrivez :

• product_description: Unknown — homepage content not accessible
• icp_fit_score: 3 (ou moins)
• icp_fit_reasoning: Insufficient evidence — homepage returned no readable content

Mode d'échec classique évité : une landing page Framer/Next.js sans texte rendu serveur, où le sous-agent projette des indices visuels ("design-forward", "Geist Mono", "Framer-built") sur l'ICP de l'utilisateur. La typographie n'est pas un produit.

Template de prompt pour sous-agent de découverte

You are a company discovery subagent. Run search queries and save results.

TOOL RULES — CRITICAL, FOLLOW EXACTLY:
1. You may ONLY use the Bash tool. No exceptions.
2. Run ALL searches in a SINGLE Bash call using && chaining.
3. BANNED TOOLS: WebFetch, WebSearch, Write, Read, Glob, Grep — ALL BANNED.
   If you use ANY banned tool, the entire run fails. Use ONLY Bash.
4. NEVER use ~ or $HOME in paths — use full literal paths.

TASK:
Run ALL of the following searches in ONE Bash command:

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

After the command completes, report back ONLY the count of results found per batch.
Do NOT analyze, summarize, or return the actual results.

Template de prompt pour sous-agent de recherche

You are a company research subagent. For each company URL, research the company and score ICP fit.

CONTEXT:
- User's company: {user_company}
- User's product: {user_product}
- ICP description: {icp_description}
- Depth mode: {depth_mode}
- Output directory: {OUTPUT_DIR}   ← write research files HERE, as a full literal path

URLS TO PROCESS:
{url_list}

TOOL RULES — CRITICAL, FOLLOW EXACTLY:
1. You may ONLY use the Bash tool. No exceptions.
2. All searches: Bash → browse cloud search "..." --num-results 10
3. All homepage/product-page content extraction:
   Bash → node {SKILL_DIR}/scripts/extract_page.mjs "URL" --max-chars 3000
   This returns structured TITLE / META_DESCRIPTION / OG_DESCRIPTION / HEADINGS / BODY and auto-falls back to browse get markdown when fetch fails or returns thin JS-rendered content.
   DO NOT hand-roll a `browse cloud fetch | sed` pipeline — it strips meta tags and doesn't parse the stdout JSON envelope. Use `browse cloud fetch` raw only for sitemap.xml, robots.txt, llms.txt.
4. BATCH all file writes: Write ALL markdown files in a SINGLE Bash call using chained heredocs (one permission prompt, not one per file).
5. BANNED TOOLS: WebFetch, WebSearch, Write, Read, Glob, Grep — ALL BANNED.
   If you use ANY banned tool, the entire run fails. Use ONLY Bash.
6. NEVER use ~ or $HOME in paths — use full literal paths.

ANTI-HALLUCINATION RULES — CRITICAL:
- NEVER infer product_description, industry, or target_audience from fonts, framework (Framer/Next.js/React), design system, or visual style. Typography is not a product.
- NEVER let the sender's 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 closely paraphrase a 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.

RESEARCH PATTERN (per company):

Phase A — Plan (skip in quick mode):
Decompose what you need to know into sub-questions based on ICP and enrichment fields.

Phase B — Research Loop:
For each sub-question (or just the homepage in quick mode):
1. Run browse cloud search with relevant query
2. Pick 1-2 most relevant URLs from results
3. Extract page content: node {SKILL_DIR}/scripts/extract_page.mjs "URL" --max-chars 3000
   (uses `--output` to avoid the stdout JSON envelope, preserves meta tags, and falls back to browse get markdown when needed)
4. Smart page discovery: use `browse cloud fetch --allow-redirects` on /sitemap.xml or /llms.txt to find relevant URLs — these are small XML/text files where the raw JSON envelope is fine. For the actual HTML pages you discover, use extract_page.mjs.
5. Extract findings: factual statements with source, confidence level
6. Accumulate findings, move to next sub-question
7. Respect step budget: quick=2-3 calls, deep=5-8, deeper=10-15

Phase C — Synthesize:
From accumulated findings:
1. Score ICP fit 1-10 (see rubric below)
2. Fill enrichment fields from findings
3. Reference specific findings in icp_fit_reasoning

ICP SCORING RUBRIC:
- 8-10: Strong match. Multiple high-confidence findings confirm fit.
- 5-7: Partial match. Some findings suggest relevance but key signals missing.
- 1-4: Weak match. Wrong segment or no apparent connection.

OUTPUT — write ALL company files in a SINGLE Bash call using chained heredocs directly to {OUTPUT_DIR}:

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

## Product
{product description paragraph}

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

Use 'COMPANY_MD' (quoted) as the heredoc delimiter to prevent shell variable expansion.

Report back ONLY: "Batch {batch_id}: {succeeded}/{total} researched, {findings_count} total findings."
Do NOT return raw data to the main conversation.

Gestion des vagues

Principe clé : maximiser le parallélisme, minimiser les prompts

Lancez autant de sous-agents que possible dans un seul message (jusqu'à ~6 appels Agent par message). Chaque sous-agent DOIT regrouper toutes ses opérations Bash pour minimiser les prompts d'autorisation.

Phase de découverte

• Lancer jusqu'à 6 sous-agents de découverte dans un seul message
• Chaque sous-agent exécute TOUTES ses requêtes dans un SEUL appel Bash avec chaînage &&
• Une fois toutes les vagues terminées, lancer node {SKILL_DIR}/scripts/list_urls.mjs /tmp
• Filtrer les URL : retirer articles de blog, actualités, annuaires, concurrents et clients existants. Garder uniquement les homepages d'entreprises.

Phase de recherche

• Le nombre d'entreprises par sous-agent varie selon la profondeur :
  • quick : ~10 entreprises par sous-agent
  • deep : ~5 entreprises par sous-agent
  • deeper : ~2-3 entreprises par sous-agent
• Chaque sous-agent écrit TOUS ses fichiers markdown dans UN SEUL appel Bash (heredocs chaînés) directement dans {OUTPUT_DIR}

Formule de dimensionnement

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

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

Gestion des erreurs

• Si un sous-agent échoue, journaliser l'erreur et continuer avec les batchs restants
• Si >50% des sous-agents échouent dans une vague, faire une pause et informer l'utilisateur
• extract_page.mjs gère déjà en interne le fallback browse cloud fetch → browse get markdown. S'il renvoie malgré tout FETCH_OK: false avec BODY vide, sauter l'entreprise et marquer product_description comme Unknown (ne pas deviner).

Compilation rapport + CSV

Une fois tous les sous-agents de recherche terminés, compiler le rapport HTML et le CSV en une commande :

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

Le script :

• Lit tous les fichiers .md dans {OUTPUT_DIR}
• Parse le frontmatter YAML + les sections du corps
• Déduplique par nom d'entreprise normalisé (garde le score ICP le plus élevé)
• Génère {OUTPUT_DIR}/index.html — page d'overview scorée
• Génère {OUTPUT_DIR}/companies/{slug}.html — une page par entreprise
• Génère {OUTPUT_DIR}/results.csv — tableur pour sheets/CRM
• Ouvre index.html dans le navigateur par défaut (flag --open)
• Imprime un résumé JSON sur stderr