agentsclimarketplace

Company report

Skill alexvui/companydudil/.claude/skills/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

Install
npx -y skills add alexvui/companydudil --skill company-report

Assembled 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.

  1. Si usage_profile est déjà fourni par la slash command (--usage=X) et appartient à {dd, sales, veille, polyvalent} → l'utiliser directement.

  2. 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)
  3. Charger Read .claude/skills/company-report/references/usage-profiles.md et extraire pour le profil retenu :

    • sections_prioritaires (ordre de lecture)
    • sections_critiques (confiance bloquante)
    • datapoints_obligatoires_par_agent
    • angles_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 :

PatternType 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èsURL (sans schéma)
sinonNAME (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 champ notes à l'utilisateur, lui demander de préciser via AskUserQuestion, puis arrêter (relancer un /report avec un identifiant précis).
  • status: resolved → continuer à l'étape 3. Si confidence: 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 :

  1. company-financials
  2. company-people
  3. company-implantations
  4. company-market
  5. company-history
  6. company-legal (nouveau)
  7. company-press (nouveau)
  8. company-clients (nouveau)
  9. 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) :

Agentddsalesveillepolyvalent
company-financialscriticalnormalnormalcritical
company-peoplecriticalcriticalnormalnormal
company-implantationsnormalcriticalnormalcritical
company-marketnormalcriticalcriticalnormal
company-historycriticaloptionalnormalnormal
company-legalcriticalnormalnormalnormal
company-pressnormalcriticalcriticalnormal
company-clientsnormalcriticalcriticalnormal
company-ecosystemcriticalnormalcriticalnormal

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 :

DatapointAgent A (valeur)Agent B (valeur)Divergence
Effectifpeople : Xfinancials : Yécart > 30 % → flagger
Effectifpeople : Ximplantations : Y (somme par site)écart > 30 % → flagger
CA récentfinancials : Xmarket : Y (mention positionnement)écart > 10 % → flagger
Date de créationresolver : Xhistory : Ydifférence > 6 mois → flagger
Dirigeant principalpeople : Nom Ahistory (dernier dirigeant cité) : Nom Bmismatch → flagger
Statut juridiqueresolver : Xlegal : Ymismatch → flagger (ex. resolver dit "in bonis", legal dit "redressement")
Société mèreresolver : Xecosystem : Ymismatch → flagger
Nombre de magasinsimplantations : Xclients (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-legal ou company-financials
  • Cessation de paiements datée ≤ 12 mois
  • Changement de dirigeant principal ≤ 6 mois (mentionné par company-people ou company-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 press ou history, 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)
  • §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) :

  1. Lecture financière consolidée
  2. Risques juridiques & passifs latents
  3. Structure capitalistique & gouvernance
  4. Walk-through M&A (valorisation indicative, périmètre cessible, key persons)
  5. BATNA repreneur
  6. Conditions suspensives recommandées

Profil sales (4 angles) :

  1. Interlocuteur cible & circuit de décision
  2. Timing & signal d'achat
  3. Argumentaire adapté (3 angles pour cette société)
  4. Concurrence directe sur le compte

Profil veille (4 angles) :

  1. Positionnement déclaré vs. réel
  2. Mouvements stratégiques 24 derniers mois
  3. Menaces structurelles
  4. Opportunités à exploiter

Profil polyvalent (4 angles originaux) :

  1. Angle prospection commerciale
  2. Angle due diligence / M&A
  3. Angle veille concurrentielle
  4. 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 dans usage-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

Keep looking

Skills are one crate of 326,506. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.