Company report
Skill orchestratrice qui génère un rapport markdown complet sur une société française à partir d'un SIRET, d'une URL ou d'un nom. Capture le cas d'usage (dd/sales/veille/polyvalent), détecte le type d'input, résout l'identité via le sub-agent company-resolver, dispatche en parallèle 9 sub-agents de recherche (financials, people, implantations, market, history, legal, press, clients, ecosystem), détecte les divergences entre sections, agrège selon le template adapté au cas d'usage, et écrit le rapport dans reports/YYYY-MM-DD-<slug>.md. Invoquée par la slash command /report.From its SKILL.md
npx -y skills add alexvui/companydudil --skill company-reportAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
13.9 KB, ~4.0k tokens by cl100k_base, as published. Nobody here has run it
Skill : company-report
Objectif
Orchestrer la génération d'un rapport société complet à partir d'un input brut (SIRET, SIREN, URL, ou nom), façonné par un cas d'usage (dd, sales, veille, polyvalent) que l'utilisateur sélectionne avant la recherche.
Input attendu
La slash command /report <input> [--usage=X] transmet :
raw_input: "<ce que l'utilisateur a tapé>"
usage_profile: "<dd | sales | veille | polyvalent ou vide>"
Étape 0 — Capture du cas d'usage
Règle : la skill DOIT connaître le usage_profile avant tout autre travail.
-
Si
usage_profileest déjà fourni par la slash command (--usage=X) et appartient à{dd, sales, veille, polyvalent}→ l'utiliser directement. -
Sinon, demander à l'utilisateur via
AskUserQuestion:Question : « Quel est le cas d'usage de ce rapport ? Cela façonne la profondeur et la priorité des sections. »
Options :
dd— Due diligence / M&A (finances, juridique, écosystème, risques)sales— Prospection commerciale (interlocuteurs, signaux, timing)veille— Veille concurrentielle (positionnement, concurrents, mouvements)polyvalent— Polyvalent (équilibré, 4 angles)
-
Charger
Read .claude/skills/company-report/references/usage-profiles.mdet extraire pour le profil retenu :sections_prioritaires(ordre de lecture)sections_critiques(confiance bloquante)datapoints_obligatoires_par_agentangles_synthèse
Si l'input raw_input est vide, demander d'abord : « Quel SIRET, URL, ou nom de société dois-je analyser ? » puis poursuivre l'étape 0.
Étape 1 — Détection du type d'input
Appliquer ces règles dans l'ordre :
| Pattern | Type détecté |
|---|---|
^\d{9}$ | SIREN |
^\d{14}$ | SIRET |
commence par http:// ou https:// | URL |
contient un . et au moins un caractère non numérique avant ou après | URL (sans schéma) |
| sinon | NAME (avertir : « Qualité moindre sans SIREN/URL ») |
Étape 2 — Résolution d'identité (séquentielle)
Invoquer le sub-agent company-resolver avec :
raw_input: "<input utilisateur>"
detected_type: "<type détecté>"
usage_profile: "<profil retenu>"
Attendre sa réponse (bloquant).
Branchement selon status :
status: not_found→ écrire un mini-rapport « Société non identifiée » listant les sources essayées, puis arrêter. Ne pas dispatcher les autres agents.status: ambiguous→ afficher la liste des candidats du champnotesà l'utilisateur, lui demander de préciser viaAskUserQuestion, puis arrêter (relancer un/reportavec un identifiant précis).status: resolved→ continuer à l'étape 3. Siconfidence: low, prévenir : « ⚠️ Identité résolue avec une confiance faible — le rapport sera produit mais ses sections risquent d'être lacunaires. Continuer ? » Attendre confirmation explicite.
Étape 3 — Dispatch parallèle des 9 sub-agents de recherche
RÈGLE CRITIQUE : invoquer les 9 sub-agents en un seul message contenant 9 appels Agent simultanés. C'est ce qui rend la génération rapide.
Les 9 agents à dispatcher :
company-financialscompany-peoplecompany-implantationscompany-marketcompany-historycompany-legal(nouveau)company-press(nouveau)company-clients(nouveau)company-ecosystem(nouveau)
Chaque appel passe en prompt le payload du resolver enrichi du profil et de la priorité :
Tu reçois ci-dessous l'identité canonique d'une société résolue, le profil de cas d'usage du rapport, et tes datapoints obligatoires. Produis la section markdown qui te correspond, en respectant strictement le format de sortie défini dans ton agent et en exécutant TOUTES les passes obligatoires pour ce profil.
# Identité canonique (resolver)
<payload YAML du resolver>
# Profil de cas d'usage
usage_profile: <dd|sales|veille|polyvalent>
priority_for_this_agent: <critical|normal|optional>
# Datapoints obligatoires pour ce profil (tu dois les rechercher activement)
extra_datapoints_required:
- "<datapoint 1>"
- "<datapoint 2>"
- ...
# Convention de recoupement
Chaque datapoint chiffré que tu retournes doit être annoté :
- `valeur (recoupé <source1> + <source2>)` si confirmé par ≥2 sources
- `valeur (<source>, source unique)` si une seule source
- `valeur (estimation <source secondaire>)` si déduit d'une source non officielle
Mappage profil → priorité par agent (à appliquer par la skill) :
| Agent | dd | sales | veille | polyvalent |
|---|---|---|---|---|
company-financials | critical | normal | normal | critical |
company-people | critical | critical | normal | normal |
company-implantations | normal | critical | normal | critical |
company-market | normal | critical | critical | normal |
company-history | critical | optional | normal | normal |
company-legal | critical | normal | normal | normal |
company-press | normal | critical | critical | normal |
company-clients | normal | critical | critical | normal |
company-ecosystem | critical | normal | critical | normal |
Datapoints obligatoires : la skill puise dans references/usage-profiles.md la liste correspondante et envoie à chaque agent ceux qui le concernent.
Gestion d'erreur : si un agent retourne une erreur ou un résultat manifestement vide :
- bandeau
> ⚠️ Section indisponible — <raison>dans le rapport - ne pas relancer plus d'une fois
- la confiance globale baisse d'un cran si l'agent était
critical
Étape 4 — Détection des divergences (recoupement croisé)
Avant rédaction, la skill compare les datapoints inter-sections et liste les divergences. Tableau de comparaison à construire :
| Datapoint | Agent A (valeur) | Agent B (valeur) | Divergence |
|---|---|---|---|
| Effectif | people : X | financials : Y | écart > 30 % → flagger |
| Effectif | people : X | implantations : Y (somme par site) | écart > 30 % → flagger |
| CA récent | financials : X | market : Y (mention positionnement) | écart > 10 % → flagger |
| Date de création | resolver : X | history : Y | différence > 6 mois → flagger |
| Dirigeant principal | people : Nom A | history (dernier dirigeant cité) : Nom B | mismatch → flagger |
| Statut juridique | resolver : X | legal : Y | mismatch → flagger (ex. resolver dit "in bonis", legal dit "redressement") |
| Société mère | resolver : X | ecosystem : Y | mismatch → flagger |
| Nombre de magasins | implantations : X | clients (logos clients-magasins) : Y | écart > 30 % → flagger |
Si divergence(s) détectée(s) → remplir la section 10 (Recoupement & divergences) du rapport. Si aucune → écrire « Aucune divergence majeure détectée entre les sections. »
Conditions d'activation du bandeau d'alerte (haut du rapport) :
- Procédure collective en cours mentionnée par
company-legaloucompany-financials - Cessation de paiements datée ≤ 12 mois
- Changement de dirigeant principal ≤ 6 mois (mentionné par
company-peopleoucompany-history) - Divergence majeure entre 2 sections sur un datapoint critique (CA ou effectif > 30 % d'écart)
Étape 5 — Agrégation et rédaction des sections 1, 11, 12, 13
Lire le template : Read .claude/skills/company-report/references/report-template.md.
Synthèse 30 secondes (en-tête)
5 puces concises, calculées à partir du retour des agents :
- Statut (forme + effectif + CA récent)
- Dirigeant principal (issu de
people) - Positionnement (issu de
market, une ligne) - Signal le plus récent (issu de
pressouhistory, daté) - Confiance globale + nb sections critiques
low
Section 1 — Carte d'identité
Remplir depuis le payload du resolver enrichi par les sections 3 (financials), 4 (implantations), 5 (legal), et les annotations de recoupement.
Sections 2 à 9
Insérer directement les markdowns retournés par les 9 agents (pas de modification, pas de paraphrase). Ordre canonique :
- §2 —
company-people - §3 —
company-financials- §3.1 —
company-ecosystem(inséré comme sous-section de §3 pour grouper la lecture finance + groupe)
- §3.1 —
- §4 —
company-implantations - §5 —
company-legal - §6 —
company-market - §7 —
company-clients - §8 —
company-history - §9 —
company-press
Section 10 — Recoupement & divergences détectées
Issue de l'étape 4. Toujours présente, vide si aucune divergence.
Section 11 — Synthèse opérationnelle (ADAPTATIVE)
Lire le profil dans usage-profiles.md et rédiger les angles correspondants :
Profil dd (6 angles) :
- Lecture financière consolidée
- Risques juridiques & passifs latents
- Structure capitalistique & gouvernance
- Walk-through M&A (valorisation indicative, périmètre cessible, key persons)
- BATNA repreneur
- Conditions suspensives recommandées
Profil sales (4 angles) :
- Interlocuteur cible & circuit de décision
- Timing & signal d'achat
- Argumentaire adapté (3 angles pour cette société)
- Concurrence directe sur le compte
Profil veille (4 angles) :
- Positionnement déclaré vs. réel
- Mouvements stratégiques 24 derniers mois
- Menaces structurelles
- Opportunités à exploiter
Profil polyvalent (4 angles originaux) :
- Angle prospection commerciale
- Angle due diligence / M&A
- Angle veille concurrentielle
- Angle sourcing fournisseur
Règle de fond : chaque angle DOIT être étayé par ≥3 datapoints chiffrés tirés des sections amont (citer le numéro de section, e.g. « voir §3 : EBITDA 867 K€ »). Pas de prose creuse.
Section 12 — Sources
Concaténer toutes les URLs citées par les 9 agents + celles du resolver. Dédupliquer par URL exacte. Regrouper par section d'origine. Format : - [titre court](url) — consulté le YYYY-MM-DD.
Section 13 — Lacunes & limites
Trois sous-sections :
13.1 Lacunes bloquantes (pour le profil)
Lacunes qui touchent un datapoint obligatoire du profil retenu. Liste impérative.
13.2 Lacunes par section
Concaténer les « Lacunes identifiées » remontées par chaque agent. Regrouper par section.
13.3 Limites méthodologiques
Bloc fixe rappelant les limites systémiques (pas d'API tierce, RBE restreint, LinkedIn anti-scraping, etc.). Texte standard depuis le template.
Étape 6 — Écriture du fichier
Calculer le slug :
slug = lowercase(canonical_name)
slug = retirer les accents (é→e, à→a, ç→c, etc.)
slug = remplacer tout caractère non [a-z0-9] par "-"
slug = compacter les "-" multiples en un seul
slug = retirer les "-" en début/fin
Chemin final : reports/<YYYY-MM-DD>-<slug>--<usage_profile>.md (date du jour).
Le suffixe --<usage_profile> permet de produire plusieurs rapports différents sur la même société à la même date.
Écrire via Write.
Étape 7 — Résumé utilisateur
Afficher à l'utilisateur un résumé court (5-8 lignes), adapté au profil :
Profil dd :
✓ Rapport généré : reports/<chemin>
• Société : <canonical_name> (SIREN <siren>) — <forme juridique>
• Statut juridique : <in bonis / redressement / etc>
• CA <année> : <chiffre recoupé>
• Procédures en cours : <nombre> (voir §5)
• Filiales identifiées : <nombre>
• Confiance globale : <high|medium|low>
• Alertes : <bandeaux activés s'il y en a>
Profil sales :
✓ Rapport généré : reports/<chemin>
• Société : <canonical_name>
• Interlocuteur cible : <nom> (<rôle>) — <linkedin si trouvé>
• Signal d'achat le plus récent : <événement daté>
• Taille de deal indicative : <fourchette>
• Email pattern : <pattern détecté>
• Confiance globale : <high|medium|low>
Profil veille :
✓ Rapport généré : reports/<chemin>
• Société : <canonical_name>
• Positionnement : <une ligne>
• Top 3 concurrents : <noms + CA>
• Mouvement stratégique récent : <événement daté>
• Awards identifiés : <nombre>
• Confiance globale : <high|medium|low>
Profil polyvalent :
✓ Rapport généré : reports/<chemin>
• Société : <canonical_name> (SIREN <siren>)
• Dirigeant principal : <nom> (<rôle>)
• CA <année> : <chiffre>
• Implantations : <nombre magasins>, <nombre entrepôts>
• Confiance globale : <high|medium|low>
• Sources : <N> URLs citées
Règles globales
- Pas de recherche directe par la skill. La skill orchestre uniquement : elle invoque les agents, agrège, écrit. Toute recherche est faite par un sub-agent.
- Parallélisme strict en étape 3. Un seul message avec 9 appels Agent simultanés.
- Aucune invention. Si un agent n'a pas trouvé une donnée, la skill ne doit pas la combler.
- Annotation de recoupement obligatoire sur tout chiffre marquant de la carte d'identité et de la synthèse 30 s.
- Détection des divergences en étape 4 : non négociable, c'est ce qui donne au rapport sa robustesse.
- Confiance globale =
min(confiance_des_sections_critiques_pour_le_profil). La liste des sections critiques est définie par profil dansusage-profiles.md. - Bandeau d'alerte : si une condition d'activation est remplie, le bandeau est OBLIGATOIRE en tête de rapport.
- Suffixe de fichier
--<profil>: permet de coexister plusieurs versions du rapport sur la même société.
What ships with it: 3 files
32.1 KB alongside SKILL.md
references/
- report-template.md6.8 KB
- search-recipes.md16.5 KB
- usage-profiles.md8.8 KB