TongyiDai/mckinsey-people-brain

Cerveau RH McKinsey

Consultant RH MBB débauché pour 200W tokens, 10 ans d'expérience, spécialisé dans les talents, l'organisation et la transformation IA.

Mode de fonctionnement principal

Ce skill décompose la tâche en deux étapes :

1. Collecte des sources officielles : Découvrir les pages candidates sur les sites MBB, extraire le corps, le titre, la date, l'URL finale, le statut et la capture originale.
2. Construction de la base de données Agent : Normaliser les URL, dédupliquer, appliquer des contrôles qualité, catégoriser par thème, et produire les résultats au format JSON, CSV et SQLite.

La réécriture vers Feishu est un adaptateur de publication après la construction de la base. Elle est optionnelle, rejouable et lisible en retour, et ne doit pas devenir la seule source de vérité de la base locale.

Périmètre d'application

Invoquer ce skill lorsque l'utilisateur demande :

• Rechercher sur les sites officiels de MBB (McKinsey, BCG, Bain) du contenu sur la gestion des talents, l'organisation, le leadership, les compétences, la performance, l'IA et l'avenir du travail.
• Mettre à jour une base de contenu MBB existante, identifier les ajouts, mises à jour, contenus restreints, corps manquants et sources dupliquées.
• Construire une base de données interrogeable par Agent à partir des enregistrements ayant passé les contrôles qualité.
• Écrire de manière incrémentielle, après autorisation de l'utilisateur, les enregistrements validés dans une Base ou un Wiki Feishu personnel.

Le périmètre des sources est fixe : les domaines officiels mckinsey.com, bcg.com, bain.com et leurs sous-domaines régionaux. Les résumés tiers, pages de résultats de recherche et pages de republication ne peuvent servir que d'indices de découverte, et ne doivent pas entrer dans le registre final des sources.

Phase 1 : Collecte des sources officielles

Lire d'abord la configuration des sources du projet et le manifest précédent. La configuration comprend au moins : cabinet, domaine officiel, mots-clés thématiques, URL initiales, rythme de collecte et nombre minimum de caractères du corps.

Les priorités sont, dans l'ordre : sitemap officiel ou index thématique, résultats de recherche interne au site, rafraîchissement des URL déjà enregistrées. Les résultats de la découverte sont d'abord écrits dans targets.json, puis chaque cible est récupérée individuellement dans fetched.json. Chaque exécution utilise un run_id unique, conserve les captures originales dans raw/ et produit collect-manifest.json.

Règles de récupération :

• Utiliser HTTPS, conserver l'URL de redirection finale, supprimer les paramètres de suivi et les fragments, générer un ID stable à partir de l'URL normalisée.
• Effectuer des tentatives limitées avec backoff pour les erreurs 429, 5xx et réseau ; écrire l'état en cas d'échec d'une seule cible, sans interrompre l'ensemble du lot.
• Respecter le robots.txt, la fréquence d'accès, les barrières de connexion et de paywall. En cas de limitation, marquer comme restricted, ne pas compléter le corps avec des résumés de recherche ou du contenu supposé.
• ok signifie que le corps atteint le seuil et que le domaine de la source, le titre et l'URL sont valides ; no_body, restricted, error doivent conserver la raison de l'échec.
• Le script de collecte est uniquement responsable de l'extraction et de l'écriture sur disque, il n'écrit pas directement dans Feishu pendant la phase de collecte.

Lorsqu'un projet dispose déjà d'un adaptateur spécifique à un site, le réutiliser ; pour un nouveau site, d'abord compléter l'adaptateur avec des tests, puis l'intégrer dans l'exécution par lots. La validation générique et la construction de la base de données utilisent les scripts de ce skill.

Phase 2 : Construction de la base de données Agent

Fusionner fetched.json avec le corpus de base historique optionnel, puis exécuter :

python3 scripts/build_agent_db.py \
  --run-dir data/runs/20260806-01 \
  --base-corpus data/agent-db/records.json \
  --min-body-chars 800

Le script effectue les actions suivantes :

• Normaliser les URL, supprimer les doublons provenant d'une même source.
• Sélectionner l'enregistrement à conserver en fonction de la qualité du corps, de l'intégrité du titre et de l'heure de récupération, enregistrer duplicate_of.
• Valider le domaine, le cabinet, le statut, la longueur du corps, le comptage de caractères et le titre.
• Classer dans les thèmes unifiés : Stratégie des talents, Conception organisationnelle, IA et avenir du travail, Compétences et apprentissage, Performance et récompenses, People Analytics, Expérience collaborateur, Leadership, Planification des effectifs.
• Produire agent-db/records.json, agent-db/source-register.csv, agent-db/agent-db.sqlite, agent-db/manifest.json.

Contrôle qualité :

python3 scripts/validate_records.py data/runs/20260806-01/fetched.json --min-body-chars 800 --strict

Seuls les enregistrements ayant passé le contrôle qualité peuvent entrer dans le corpus de corps de texte référençable. Les enregistrements restreints ou sans corps peuvent entrer dans un ensemble de surveillance, mais doivent comporter le statut et la raison de l'échec.

Phase 3 : Réécriture incrémentielle vers Feishu

Avant la réécriture, confirmer le profil CLI actuel, identity=user, la Base/Wiki cible et le mappage des champs. Feishu personnel et Feishu entreprise sont deux locataires indépendants ; on ne peut pas déduire la cible du profil par défaut.

Il est recommandé d'utiliser la valeur normalisée de source_url comme clé d'idempotence :

1. Lire les champs et les enregistrements existants de la table cible.
2. Construire un index URL → record_id.
3. Créer un enregistrement pour les nouvelles URL, mettre à jour les champs nécessaires pour les URL existantes, ne mettre à jour que le statut et la raison de l'échec pour les enregistrements restreints.
4. Après chaque lot d'écriture, relire immédiatement par URL pour vérifier titre, statut, date, thème et lien source.
5. En cas d'échec d'écriture ou d'expiration de l'identité, s'arrêter et conserver les artefacts de construction locale et la liste des éléments à écrire.

Ne pas soumettre sur GitHub : le nombre de lignes de la Base, les tokens Wiki, l'ID du locataire, les URL internes, les jetons d'accès, les chemins personnels ou les captures d'écran de pages web originales.

Contrat d'enregistrement

Les champs minimaux d'un enregistrement sont : id, firm, title, source_url, final_url, published_date, status, failure_reason, body_text, body_chars, tags, themes, fetched_at_utc.

Les statuts autorisés sont uniquement : ok, restricted, no_body, error. Voir les règles détaillées dans references/data-contract.md.

Liste de vérification pour la revue de code

• La collecte et la construction de la base peuvent être exécutées indépendamment ; les échecs sont traçables jusqu'au run_id et à l'URL.
• Une réexécution ne produit pas d'enregistrement en double pour une même URL ; la sortie est écrite dans un fichier temporaire puis remplacée de manière atomique.
• La capture originale, le résultat nettoyé et le manifest sont traçables les uns par rapport aux autres.
• Les sources publiques et les données internes sont séparées ; le dépôt ne contient ni token, cookie, chemin personnel, identifiant de locataire, ni données métier réelles.
• Les erreurs HTTP, le corps vide, les changements de structure du site, les clés dupliquées dans la base et les échecs d'authentification Feishu ont tous un résultat explicite.
• Les tests couvrent la normalisation des URL, les restrictions de domaine, le seuil de corps, la préférence de déduplication et les statuts d'échec.

Fichiers de référence

• data-contract.md : Champs d'enregistrement, statuts, contrôles qualité et structure de sortie.
• source-adapters.md : Découverte des sources officielles MBB et conventions des adaptateurs de site.
• feishu-publish.md : Validation d'identité Feishu, écriture idempotente et exigences de relecture.
• scripts/validate_records.py : Script de validation qualité indépendant.
• scripts/build_agent_db.py : Script de construction de base de données indépendant.