L'Onboarding d'Équipe dans Claude Code

Problème : Tu as passé trois mois à construire un harnais Claude Code personnalisé. Des dizaines de skills. Quelques commandes slash personnalisées. Deux ou trois sous-agents. Tu l'utilises comme une seconde nature. Chaque nouveau coéquipier qui essaie de l'utiliser est perdu dans la première heure.

Victoire rapide : Ajouté dans la v2.1.101. Lance la commande une fois à la racine de ton projet et elle écrit un doc complet de montée en compétence basé sur comment tu travailles vraiment :

claude -p "/team-onboarding"

Claude lit tes 30 derniers jours d'utilisation locale, scanne le dossier .claude/, inspecte CLAUDE.md, parcourt la structure du projet, et dépose un fichier markdown que tu peux remettre à un nouveau coéquipier. Pas de README manuel. Pas de tableur de "connaissances tribales". Pas d'audit d'onboarding trimestriel.

Ce Qu'Est Vraiment /team-onboarding

C'est une commande slash intégrée qui génère un guide de montée en compétence à partir de deux sources de données très différentes. Données structurelles : tes .claude/commands/, .claude/skills/, .claude/agents/, CLAUDE.md, serveurs MCP configurés, repos voisins. Données comportementales : à quelle fréquence tu as lancé chaque commande dans les 30 derniers jours, quels types de travail ces commandes correspondent, quels serveurs MCP tu as touchés.

Les deux sources sont combinées en un doc markdown qui se lit comme un ingénieur senior écrivant un guide du premier jour pour la nouvelle recrue qui l'accompagne.

Ce n'est pas une interface d'onboarding en temps réel. Ce n'est pas un chat. Ça tourne une fois, écrit un fichier, et s'arrête. Le fichier que tu obtiens est un snapshot de comment l'outil a été utilisé dans ton repo.

Ce Qu'Il Lit

Six entrées alimentent le guide. Chaque entrée est locale. Rien ne quitte ta machine sauf les appels à Claude lui-même.

L'historique d'utilisation est la raison pour laquelle cette fonctionnalité est intéressante. N'importe quel outil peut lister des fichiers. Très peu peuvent dire à une nouvelle recrue que l'ingénieur senior lance /claude-scout sept fois par mois et n'a jamais touché MCP. Cette deuxième couche est ce qui transforme une liste de fichiers en doc de montée en compétence.

À Quoi Ressemble La Sortie

Voici un vrai exemple, non édité, d'un repo content-factory en utilisation active depuis un mois :

# Welcome to Build This Now

## How We Use Claude

Based on speedy_devv's usage over the last 30 days:

Work Type Breakdown:
  Write Docs        █████████░░░░░░░░░░░  44%
  Build Feature     ███████░░░░░░░░░░░░░  33%
  Plan Design       ████░░░░░░░░░░░░░░░░  22%

Top Skills & Commands:
  /claude-scout     ████████████████████  7x/month
  /carousel         ██████░░░░░░░░░░░░░░  2x/month
  /compact          ██████░░░░░░░░░░░░░░  2x/month
  /claude-research  ███░░░░░░░░░░░░░░░░░  1x/month
  /resume           ███░░░░░░░░░░░░░░░░░  1x/month

Top MCP Servers:
  _None configured yet_

## Your Setup Checklist

### Codebases
- [ ] btn-content-factory (this repo, content generation pipeline)
- [ ] claude-code-seo-machine, sibling repo (blog paraphrase + SEO)
- [ ] build-kit-template, the framework itself

### MCP Servers to Activate
- [ ] _None in use yet_

### Skills to Know About
- /claude-scout: hourly scout for Anthropic/Claude Code news. Most-used
  command on the team.
- /carousel: builds an Instagram carousel via the carousel-designer +
  carousel-evaluator GAN loop.
- /blog-post: turns a carousel into a /blog/guide/ MDX page + hero image.

## Team Tips
_TODO_

## Get Started
_TODO_

Cinq sections reviennent. L'en-tête tire le nom de l'équipe depuis CLAUDE.md. "How We Use Claude" est la couche comportementale. "Your Setup Checklist" est structurelle. "Team Tips" et "Get Started" sont des placeholders interactifs que la commande te demande de remplir après la première exécution.

Les diagrammes en barres ne sont pas décoratifs. Ce sont des caractères ASCII compatibles avec les shells, donc tu peux coller le fichier n'importe où et le rythme du travail de l'équipe est visible d'un coup d'œil. Un nouveau coéquipier qui le parcourt sait, en dix secondes, que cette équipe documente plus qu'elle ne construit, vit dans /claude-scout, et n'a pas de MCP câblé. C'est un meilleur contexte que la plupart des decks d'onboarding.

Comment Le Lancer

Deux façons de l'invoquer. Les deux atterrissent sur la même sortie.

Lance en mode headless, pipe vers un fichier :

claude -p "/team-onboarding" > ONBOARDING.md

Ou lance dans une session interactive :

/team-onboarding

La version interactive pose trois questions de suivi après le premier brouillon. Comment s'appelle l'équipe. S'il y a une bonne première tâche pour la nouvelle recrue. Quels conseils d'équipe tu veux noter qui ne sont pas déjà dans CLAUDE.md. Réponds-y et les sections _TODO_ se remplissent. Passe-les et le fichier sort avec les placeholders.

La version headless ne pose pas de questions. Elle écrit le brouillon tel quel, sections _TODO_ et tout.

Jour 1 vs. Semaine 1

Voilà la partie que la plupart des gens ratent. La commande mélange données structurelles et données comportementales. Les données structurelles existent dès le premier jour. Les données comportementales non.

Un clone frais de ton repo sans historique d'utilisation te donne un doc à moitié rempli. Tu obtiens la checklist de setup, l'inventaire des skills, la liste MCP. Tu n'obtiens pas la ventilation des types de travail, les barres de fréquence, ou le signal qui dit à la nouvelle recrue quelle commande est la plus utilisée.

Lance la commande trop tôt et la sortie ressemble à une liste sèche de fichiers. Lance-la après une semaine de vrai travail et elle ressemble à un ingénieur senior qui l'a écrite pour toi.

Le bon plan, ce n'est pas "la nouvelle recrue le lance le jour 1." Le bon plan, c'est "l'ingénieur expérimenté le lance sur son propre environnement, édite la sortie, et remet le fichier curatéà la nouvelle recrue."

Livre-Le Avec Ton Harnais

Si tu maintiens un framework, un template, ou une boîte à outils interne que d'autres personnes utilisent, la commande devient une fonctionnalité de distribution.

Lance /team-onboarding dans ton environnement de dev principal. Ton historique d'utilisation est riche maintenant. Tu obtiens la couche comportementale complète. Supprime les chemins personnels que tu ne veux pas partager. Commite le résultat dans ton repo sous docs/how-we-use-claude-code.md. Livre-le avec ta prochaine release.

Tes utilisateurs obtiennent maintenant quelque chose qu'aucun boilerplate ou starter kit n'a jamais donné. Un snapshot de comment les gens qui ont construit le framework l'utilisent vraiment au quotidien. Pas la version marketing. Pas la liste de fonctionnalités. Les vrais patterns d'utilisation.

Rafraîchis-le à chaque release. Les nouvelles commandes que tu as ajoutées apparaissent automatiquement parce que tu les as utilisées. Les nouveaux skills que tu as câblés apparaissent parce que le scan structurel les attrape. Les vieilles commandes que tu as arrêté d'utiliser disparaissent du top de la liste. Le doc évolue avec l'outil, sans que tu écrives une seule phrase à la main.

Le même pattern fonctionne dans une entreprise. Lance-le sur l'environnement de l'ingénieur principal. Commite la sortie comme fichier canonique "how we use Claude Code" de ton équipe. Revois-le une fois par trimestre. Mets à jour quand ça dérive.

Configuration et Contrôle

Trois réglages à connaître.

Destination de sortie. Pipe le lancement headless où tu veux. Dans un fichier repo, dans un wiki d'équipe, dans un doc partagé. La sortie est du markdown brut avec des barres compatibles ASCII.

Fenêtre de lookback. Par défaut 30 jours. Pour un ingénieur senior qui est dans le repo depuis des mois, c'est la bonne fenêtre. Pour un projet court, 30 jours peut couvrir tout ce que tu as jamais fait.

Questions de suivi interactives. La version interactive pose des questions. La version headless les saute. Si tu veux scripter tout le flux, utilise headless et remplis les sections _TODO_ à la main. Si tu veux que Claude t'aide à rédiger les conseils d'équipe, utilise interactive.

Il y a aussi un signal caché en bas du fichier. Un commentaire HTML qui lit onboarding buddy mode. C'est un hook de suivi. La prochaine fois qu'un coéquipier ouvre une session Claude Code dans le même repo, Claude se traite lui-même comme le buddy d'onboarding pour ce fichier. Tu remets le doc markdown à la nouvelle recrue avec Claude Code lui-même. Claude les guide à travers le doc, une section à la fois, en répondant aux questions en chemin.

Meilleures Pratiques

Lance-le sur l'environnement avec l'utilisation la plus riche. La couche comportementale ne paie que si la commande a de vraies données à lire. Ne le lance pas sur un clone frais. Lance-le sur le laptop où le travail se passe vraiment.

Édite avant de livrer. Le premier brouillon a des chemins personnels, des références à des repos voisins, et parfois le handle GitHub d'un coéquipier intégré. Nettoie ça avant de commiter le fichier. Traite la sortie comme un premier brouillon, pas un doc final.

Régénère à chaque release. Configure un script just onboarding ou npm. Une ligne, une commande. Relance quand tu coupes une nouvelle version. Le doc reste à jour sans que tu y touches.

Associe-le à CLAUDE.md. CLAUDE.md est tes règles pour l'IA. Le doc d'onboarding est tes règles pour l'humain. Ils se complètent. L'un dit à Claude comment se comporter. L'autre dit à la nouvelle recrue comment l'équipe fonctionne.

Lis la sortie toi-même. La première fois que tu le lances, passe cinq minutes à lire ce que Claude a remarqué sur ton propre travail. Tu vas apprendre quelque chose. La plupart des ingénieurs ne connaissent pas leurs trois principales commandes avant de voir le diagramme en barres.

Prochaines Étapes

• Configure CLAUDE.md pour ancrer les règles de ton équipe pour Claude
• Explore auto memory pour la connaissance par projet que Claude écrit pour lui-même
• Apprends le répertoire .claude/rules/ pour des instructions de projet modulaires
• Lis sur les skills personnalisés pour comprendre ce que ton doc d'onboarding inventorie
• Regarde les équipes d'agents si ton workflow s'étend sur plusieurs sous-agents en parallèle

L'onboarding d'équipe boucle la boucle entre ce que tu as construit et ce que ton équipe peut vraiment utiliser. Ton harnais arrête d'être un cockpit personnel et devient un établi partagé. Lance-le une fois, remets le fichier à la nouvelle recrue, et reviens à livrer.