Claude Code Skills : les commandes utiles en équipe

Une bonne commande d’équipe précise les informations à fournir, les éléments à examiner et le format du résultat attendu. Voyez-la comme une fiche de travail rangée à côté du code. Il suffit de saisir son nom pour appliquer cette fiche à la tâche en cours.

Commencez par /plan, /diff, /context et /compact. Ajoutez ensuite /team-pr-check à partir des modèles ci-dessous. La revue de code est un bon premier cas d’usage : les mêmes questions sur les permissions, les données et les tests reviennent à chaque modification.

Quelles commandes Claude Code faut-il connaître ?

Saisissez ces commandes au début d’un message dans Claude Code. Les crochets indiquent les arguments facultatifs ; les chevrons, les arguments obligatoires. Cette sélection reprend la syntaxe du référentiel des commandes d’Anthropic, vérifié le 13 octobre 2026. La disponibilité varie selon la plateforme, l’offre et l’environnement.

Utilisez /compact pour poursuivre le même travail et /clear pour passer à un autre. Si vous développez une fonctionnalité, une instruction utile est /compact keep the acceptance criteria, unresolved risks, and exact test commands.

/release-notes ouvre le journal des modifications de Claude Code. Cette commande ne rédige pas les notes de version de votre application. Le modèle personnalisé présenté plus bas porte donc volontairement un autre nom.

Pour intégrer ces commandes à vos habitudes de travail, consultez les bonnes pratiques de Claude Code.

Les skills fournis apparaissent aussi dans le menu des commandes

Certaines entrées du menu donnent à Claude une procédure à suivre. Ce sont des skills fournis avec l’outil, à distinguer des commandes fixes de la CLI :

• /code-review examine un diff ou une autre cible prise en charge. /review est son alias. Ajoutez --fix pour demander des modifications, ou --comment pour demander la publication de commentaires de revue.
• /simplify examine le code modifié pour le simplifier et applique les corrections.
• /verify compile et exécute l’application pour vérifier son comportement.
• /doctor diagnostique les problèmes de configuration et propose des correctifs.

Choisissez une revue simple si vous souhaitez lire les constats avant toute modification. Les syntaxes complètes, les prérequis et la disponibilité de ces commandes figurent dans les entrées consacrées aux skills fournis du référentiel des commandes.

Claude Code Skills : créer ses propres commandes

Pour toute nouvelle procédure, placez un fichier d’instructions Markdown dans .claude/skills/<name>/SKILL.md, au sein du dépôt. Versionnez-le pour que vos collègues disposent de la même procédure. Réservez ~/.claude/skills/<name>/SKILL.md à vos procédures personnelles.

L’ancien format .claude/commands/<name>.md fonctionne toujours. Les deux formats créent des commandes /<name>. Un dossier de skill peut aussi contenir des modèles, des documents de référence et des scripts. Préférez ce format lorsque la procédure s’étoffe. Guide des skills d’Anthropic

D’où viennent les commandes des plugins et de MCP ?

Les plugins regroupent des fonctionnalités pour les rendre réutilisables. Leurs dossiers skills/<name>/SKILL.md créent des commandes préfixées par le nom du plugin, comme /plugin-name:skill-name. Les anciennes commandes de plugins se trouvent dans commands/. Ces dossiers doivent être à la racine du plugin, à côté du dossier .claude-plugin/ qui contient le manifeste, et non à l’intérieur de celui-ci. Utilisez /plugin pour gérer les plugins, puis /reload-plugins après une modification. Composants des plugins

Commencez par des skills de projet tant que la procédure concerne une seule base de code. Envisagez un plugin lorsque vous devez maintenir et diffuser la même procédure dans plusieurs dépôts. Le guide des meilleurs plugins Claude Code présente des solutions existantes à évaluer avant d’en créer une autre.

Les prompts MCP proviennent des serveurs connectés. MCP, pour Model Context Protocol, relie Claude Code à des outils et à des données externes. Un serveur peut aussi proposer des prompts réutilisables. Le menu les affiche sous la forme /servername:promptname (MCP) ; /mcp__servername__promptname permet également de les appeler. Ils n’apparaissent que si le serveur connecté expose ces prompts. Une intégration qui fournit des outils ne propose pas automatiquement tous les prompts dont vous pourriez avoir besoin. Documentation des prompts MCP

Les arguments des prompts MCP sont séparés par les espaces et suivent les paramètres déclarés par le serveur. Le résultat du prompt est ajouté à la conversation. Ne supposez pas qu’un prompt de serveur traite les arguments comme un skill local.

Créer le fichier et lui transmettre les bonnes informations

Le frontmatter est le petit bloc de paramètres YAML qui précède les instructions Markdown. Le délimiteur d’ouverture --- doit figurer sur la toute première ligne du fichier. Voici les champs utiles pour ces modèles :

allowed-tools accorde une autorisation ; ce champ ne limite pas l’accès aux seuls outils listés. Tous les champs du frontmatter sont facultatifs ; description est recommandé. Les anciens fichiers de commandes acceptent les mêmes champs, à l’exception de name et de paths. Référence du frontmatter

Arguments : $ARGUMENTS insère l’intégralité de la chaîne saisie. $0 ou $ARGUMENTS[0] désigne le premier argument ; $1, le deuxième. Les arguments nommés correspondent aux positions dans l’ordre. Placez entre guillemets une valeur positionnelle qui contient plusieurs mots. argument-hint décrit les entrées attendues ; la procédure doit tout de même les vérifier. Substitution des arguments

Les modèles omettent name : le nom vient donc du dossier. Leur frontmatter fonctionne aussi dans l’ancien format de fichier de commande. Conservez les informations durables sur le dépôt dans la mémoire d’équipe CLAUDE.md, et les étapes propres à une tâche dans le skill correspondant.

Cinq commandes personnalisées à copier pour votre équipe

Créez chacun des dossiers indiqués ci-dessous et collez le bloc correspondant dans SKILL.md. Lancez /reload-skills pour que les nouveaux fichiers soient détectés. Ces modèles originaux sont à adapter à vos besoins : ce ne sont ni des commandes fournies par Anthropic ni des résultats de tests que nous prétendons avoir obtenus.

L’ordre proposé donne la priorité aux vérifications techniques récurrentes, puis à la communication. Les modèles s’appuient autant que possible sur les éléments présents dans le dépôt local. Ils peuvent produire un résultat utile sans connexion à un outil de suivi des tickets ou à un service de PR.

Une checklist de revue de PR pour les modifications qui touchent aux données clients

Une petite équipe SaaS peut utiliser cette commande avant de demander une revue humaine. Elle pose toujours les mêmes questions sur l’isolation des tenants, les autorisations et la couverture de tests, même lorsque l’auteur est pressé. Elle facilite une transmission plus homogène : chaque constat renvoie à un emplacement du code et à un scénario de défaillance.

Enregistrez le fichier sous .claude/skills/team-pr-check/SKILL.md. Lancez /team-pr-check main pour examiner la branche courante par rapport à son ancêtre commun avec main.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

Une checklist devient utile lorsqu’elle reflète les défaillances que votre équipe rencontre réellement. Remplacez les vérifications génériques par celles qui comptent pour votre produit : propriété des comptes, état de la facturation ou permissions héritées des équipes, par exemple.

Un correctif qui commence par un test pour les bugs reproductibles

Un fondateur qui maintient un produit en production peut utiliser cette commande lorsqu’un signalement permet de reproduire concrètement le bug. Le comportement défaillant et le test de non-régression font alors partie de la tâche : un correctif qui semble plausible ne suffit plus à lui seul.

Enregistrez le fichier sous .claude/skills/team-test-first-fix/SKILL.md. Lancez /team-test-first-fix duplicate webhook events create duplicate invoices.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

Cette approche convient aux défauts reproductibles. Pour un incident intermittent en production dont les éléments manquent, commencez par enquêter plutôt que de pousser la commande à inventer un test en échec.

Préparer une migration avant de toucher à un système partagé

Une équipe qui modifie un schéma de base de données ou remplace une API peut utiliser cette commande pour faire ressortir les questions d’ordre des opérations et de compatibilité avant de commencer l’implémentation. Le résultat attendu est un plan que l’on peut discuter, notamment sur la coexistence des anciennes et des nouvelles versions.

Enregistrez le fichier sous .claude/skills/team-migration-plan/SKILL.md. Lancez /team-migration-plan "billing storage" "new invoice schema".

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

Demander un plan ne change pas le mode d’autorisation de Claude Code. Si vous souhaitez aussi placer la session en Plan Mode, saisissez /plan avant d’appeler ce skill. La procédure écrite et les permissions des outils de la session sont deux réglages distincts. Plan Mode

Rédiger les notes de version de votre produit

Un développeur chargé des livraisons peut utiliser cette commande pour transformer un ensemble délimité de modifications en brouillon destiné aux clients. Elle réduit le travail nécessaire pour traduire les commits en effets concrets pour les utilisateurs, tout en exigeant un élément probant pour chaque affirmation.

Enregistrez le fichier sous .claude/skills/team-release-notes/SKILL.md. Lancez /team-release-notes previous-release HEAD, en remplaçant previous-release par un tag ou un commit existant.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

Un intervalle de commits prouve ce qui a changé dans le dépôt. Il ne prouve pas quels clients ont reçu ces modifications. Vérifiez l’état du déploiement avant de publier le brouillon.

Préparer le récapitulatif hebdomadaire de l’équipe

Un responsable technique peut utiliser cette commande pour préparer le point hebdomadaire destiné aux équipes produit et support. Elle distingue le travail fusionné des livraisons vérifiées, afin de ne pas annoncer par inadvertance une fonctionnalité encore derrière un flag.

Enregistrez le fichier sous .claude/skills/team-weekly-changelog/SKILL.md. Lancez /team-weekly-changelog START_DATE END_DATE main, en remplaçant les dates par des horodatages ISO qui précisent leur fuseau horaire. La période inclut la borne de début et exclut celle de fin.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

Gardez des procédures distinctes pour les notes de version et les points hebdomadaires. Une livraison porte sur un ensemble précis de modifications du code et s’adresse aux clients. Un point hebdomadaire couvre une période donnée et peut inclure du travail utile qui n’a pas encore été livré.

Comment savoir si une commande mérite d’être conservée ?

Mesurez le travail récurrent autour du modèle, plutôt que l’impression produite par sa première réponse.

Pour calculer la valeur hebdomadaire : nombre d’exécutions × (ancien temps de préparation et de correction − nouveau temps de préparation et de correction) × coût horaire de l’équipe − dépenses supplémentaires liées au modèle − temps de maintenance valorisé à ce même coût horaire. Utilisez vos propres mesures. Un prompt plus long peut coûter davantage s’il génère plus de travail de relecture, même s’il donne l’impression d’une automatisation plus poussée.

Le poste le plus susceptible d’évoluer est le temps que les développeurs seniors passent à expliquer la même procédure et à compléter un travail mal transmis. La procédure doit aussi être entretenue lorsque l’architecture ou le processus de livraison change.

Une commande enregistrée consomme toujours de l’usage du modèle lorsque Claude l’exécute. /usage affiche des estimations du coût en tokens et des informations sur l’utilisation de l’offre ; une estimation de coût API affichée à l’écran n’est pas une facture d’abonnement. Documentation des coûts d’Anthropic

Deux pistes de produits autour de ces commandes

Ces modèles font de bons outils internes. Pour en faire un produit, il faut un avantage plus difficile à reproduire que le simple stockage d’un prompt.

La piste la plus solide : des vérifications de revue propres au dépôt

Une petite équipe logicielle pourrait payer pour un ensemble de vérifications de revue maintenu dans le temps et adapté à ses zones à risque : quelles tables appartiennent à un compte, quelles actions touchent à la facturation et quels tests doivent accompagner une modification.

Le 13 octobre 2026, l’aperçu des mots-clés DataForSEO pour Google aux États-Unis, en anglais, indiquait 1,300 recherches mensuelles estimées pour « ai code review ». Ce chiffre signale un intérêt pour la tâche, pas une demande pour un plugin Claude Code en particulier. Aperçu des mots-clés DataForSEO

Une première version commercialisable pourrait réunir une checklist de projet, des notes d’architecture et un jeu d’évaluation fondé sur des bugs passés. Avant de la distribuer sous forme de plugin, faites-lui produire, sur ces exemples, des constats étayés par des éléments vérifiables.

La difficulté vient de la concurrence : Claude Code intègre déjà des fonctions de revue, et CodeRabbit commercialise des outils de revue de code. Un prompt de revue générique différencie peu le produit. Je ne retiendrais cette piste qu’avec un accès à l’historique des défaillances d’une équipe précise et une personne chargée de maintenir la pertinence des vérifications.

Une piste plus modeste : communiquer sur les livraisons avec des preuves

Une équipe produit pourrait utiliser un workflow maintenu dans le temps qui transforme les modifications du dépôt en notes de version pour les clients et en synthèse interne pour le support, avec des références aux sources et une vérification explicite de l’état du déploiement.

Le même aperçu des mots-clés indiquait 70 recherches mensuelles estimées pour « release notes generator ». Le signal de recherche reste modeste : je commencerais donc par une prestation ou un workflow interne avant de développer un logiciel autonome. Aperçu des mots-clés DataForSEO

La version minimale pourrait produire des brouillons à partir d’un intervalle Git choisi, dans le format habituel de l’équipe. Le plus difficile est de relier les modifications aux flags, aux déploiements et à la disponibilité réelle pour les clients. La commande peut organiser les preuves ; elle ne peut pas créer celles que l’équipe ne consigne pas.

Les limites à connaître sur une base de code d’entreprise

Une commande standardise les instructions. Vos tests, vos revues et vos contrôles de livraison restent les critères qui déterminent si le résultat est acceptable. Considérez les cinq modèles comme des procédures de départ et examinez leurs modifications au même titre que celles du code de l’application.

Le contenu complet d’un skill est chargé lorsqu’il est utilisé : gardez donc la procédure concise et placez les références détaillées dans des fichiers annexes. Les skills personnels peuvent prendre le pas sur les skills de projet du même nom ; dans les sessions locales du terminal, des skills peuvent aussi masquer des commandes intégrées. Choisissez des noms distinctifs et vérifiez la source lorsque vos collègues obtiennent des comportements différents. Chargement et priorité des skills

Configurez séparément les véritables règles d’autorisation des outils. Une phrase comme « revue uniquement » indique à Claude votre intention ; elle n’impose aucune restriction au niveau du système d’exploitation. Permissions de Claude Code

Par quoi commencer lundi ?

Versionnez d’abord /team-pr-check. Remplacez ses points génériques par les vérifications que votre dernière modification problématique aurait dû passer. Exécutez-la sur une modification terminée dont vous connaissez le résultat, comparez les constats au problème réel, puis ajustez la procédure avant d’en faire une habitude d’équipe. Ajoutez les commandes de notes de version et de récapitulatif hebdomadaire lorsque leurs formats de sortie font consensus.

Pour relier ces workflows à vos systèmes métier, je conçois des automatisations IA autour des vérifications dont votre équipe a réellement besoin.