Commandes slash Claude Code : faire de /review, /handoff et /release des standards d'équipe

Vous recollez encore la même checklist de review. Avant une release, vous reconstruisez les étapes de mémoire. À la fin d’une longue session Claude Code, il faut encore écrire à la main ce qui a changé, ce qui a été vérifié et ce qui reste risqué. Plus un agent de développement devient utile, plus ces petites répétitions méritent d’être structurées.

Les commandes slash personnalisées transforment ces prompts répétés en noms courts que l’équipe partage. Un /review, un /handoff ou un /release n’est pas seulement un raccourci. Bien conçu, c’est une règle d’équipe : comment relire un diff, comment transmettre le contexte et comment décider si une livraison peut avancer.

Cet article suit la documentation officielle Claude Code Skills et la référence Commands, vérifiées le 3 juin 2026. Le point important est que les commandes personnalisées ont été intégrées aux Skills. Les fichiers existants dans .claude/commands/*.md continuent de fonctionner, mais les nouveaux workflows d’équipe sont généralement plus propres sous .claude/skills/<name>/SKILL.md.

L’idée : une commande est une procédure réutilisable

Dans Claude Code, une commande est un message qui commence par / au début d’une session. La référence officielle précise que le texte après le nom de la commande est transmis comme argument. Ainsi, /release 1.8.0 peut passer 1.8.0 comme version, et /handoff frontend reviewer peut indiquer à qui s’adresse la note de passation.

Un Skill est un paquet d’instructions réutilisable pour Claude. En termes simples, c’est un petit playbook : quand l’utiliser, quelles étapes suivre, quelles entrées lire et quelle forme de sortie produire. Les anciens fichiers de .claude/commands/ restent valides, mais les Skills apportent une structure de dossier, du frontmatter, des fichiers de support, des arguments nommés et un processus de review plus visible.

Le piège concret est le nom. Les versions actuelles de Claude Code peuvent déjà afficher /review, /code-review ou /security-review. Avant de créer votre propre /review, tapez / et vérifiez le menu. Si le nom existe déjà, choisissez /team-review, /review-note ou un nom propre à votre équipe. L’article parle du modèle de review; le nom exact doit éviter les collisions chez vous.

Emplacement des fichiers : privilégier Skills, garder Commands pour compatibilité

Une règle d’équipe doit vivre dans le projet, pas seulement dans le dossier personnel d’un développeur. Les Skills de projet peuvent être committés, relus en pull request et versionnés avec le dépôt. Les Skills personnels restent utiles pour des routines privées, mais ils ne doivent pas porter les règles communes.

Emplacement	Exemple	Usage recommandé
Skill de projet	.claude/skills/team-review/SKILL.md	Reviews, releases, enquêtes et onboarding partagés
Command de projet	.claude/commands/handoff.md	Commandes légères existantes ou compatibilité pendant une migration
Skill personnel	~/.claude/skills/my-note/SKILL.md	Notes et routines privées
Command personnel	~/.claude/commands/my-command.md	Raccourcis temporaires

Une structure lisible ressemble à ceci :

.claude/
├── commands/
│   └── handoff.md
└── skills/
    ├── team-review/
    │   ├── SKILL.md
    │   └── checklists/
    │       └── review.md
    └── release-prep/
        ├── SKILL.md
        └── scripts/
            └── collect-release-notes.sh

Le modèle mental tient en une phrase : le dépôt stocke la procédure, le menu / l’expose comme commande, l’utilisateur passe des arguments, puis Claude Code combine tout avec le contexte courant.

flowchart LR
  A[".claude/skills ou .claude/commands"] --> B["Commande comme /team-review"]
  B --> C["Arguments : $ARGUMENTS ou $version"]
  C --> D["Claude Code charge les instructions"]
  D --> E["Review, handoff ou préparation de release"]
  E --> F["Un humain relit et décide de merger ou publier"]

Après ajout ou modification d’un Skill, vérifiez qu’il apparaît dans le menu /. Si la session en cours ne le détecte pas, utilisez /reload-skills ou ouvrez une nouvelle session Claude Code. Vérifiez aussi la description, car c’est souvent par elle que les collègues découvrent la commande.

Modèle de départ à copier

Commencez simple. L’exemple ci-dessous crée /team-review, ce qui évite un conflit probable avec un /review intégré.

mkdir -p .claude/skills/team-review
cat > .claude/skills/team-review/SKILL.md <<'EOF'
---
description: Review the current change with the team's checklist before a pull request or merge.
argument-hint: [target-branch-or-path]
disable-model-invocation: true
---

You are performing a read-only team review.

Target: $ARGUMENTS

If the target is empty, ask which diff, branch, or path to review before scanning broadly.
Do not edit files.
Do not run destructive commands.

Review from these perspectives:
1. Correctness bugs and edge cases
2. Security and privacy risks
3. Test coverage and missing verification
4. Consistency with existing code patterns
5. Documentation, migration notes, and user-facing copy

Output:
- Findings first, ordered by severity
- File path and line number when available
- One short suggestion for each issue
- "No blocking findings" only if you found none
EOF

Appelez-le ensuite avec /team-review main, /team-review src/auth ou une cible précise. disable-model-invocation: true empêche Claude de choisir ce Skill automatiquement. Pour une review ou une release, c’est préférable : ce sont des points de contrôle déclenchés volontairement par une personne.

Cas d’usage 1 : faire de /review la checklist de l’équipe

La valeur d’une commande de review vient de la constance. Sans checklist partagée, une personne regarde surtout les noms, une autre la sécurité, une autre les tests. La commande doit fixer la sévérité, le périmètre et le format de sortie pour aligner Claude et les humains.

Si votre environnement possède déjà /review, utilisez team-review.md ou un Skill team-review. Sinon, .claude/commands/review.md peut toujours créer /review.

---
description: Team review checklist for the current branch or specified path.
argument-hint: [branch-or-path]
disable-model-invocation: true
---

Review target: $ARGUMENTS

Read the diff or files related to the target and report only review findings.
Do not rewrite code unless the user asks for fixes after the review.

Severity:
- P0: data loss, auth bypass, secret leak, production outage
- P1: correctness bug, missing validation, broken user flow
- P2: maintainability, unclear naming, duplicated logic
- P3: optional cleanup

Required checks:
1. Is the change scoped to the request?
2. Are tests or manual verification enough for the risk?
3. Are error paths and empty states handled?
4. Does the code follow existing local patterns?
5. Could the change break monetization links, analytics, or release notes?

Return a short summary after the findings.

La ligne clé est “Do not rewrite code”. Une review qui modifie les fichiers sans demande explicite devient une tâche d’implémentation. Gardez la première passe en lecture seule, puis lancez une correction séparée si les findings sont acceptés.

Cas d’usage 2 : /handoff pour la prochaine personne ou le prochain agent

Une longue session perd de la valeur si sa fin est floue. Une commande de handoff transforme la clôture de la tâche en note structurée pour vous demain, pour un collègue ou pour un autre agent.

---
description: Create a concise handoff note for the current task.
argument-hint: [next-owner-or-audience]
disable-model-invocation: true
---

Create a handoff note for: $ARGUMENTS

Include these sections:
1. Goal: what the task was trying to achieve
2. Changed files: important files and why they changed
3. Decisions: tradeoffs or assumptions made during the work
4. Verification: commands run, screenshots checked, or checks not run
5. Risks: unresolved issues, fragile areas, or things needing human review
6. Next steps: the smallest useful next action

Keep it factual. Do not hide failed attempts. If something was not verified, say so clearly.

C’est très utile pour les sites monétisés et les applications en production. Liens internes, CTA, événements d’analytics, captures d’écran et vérifications manuelles s’oublient vite quand plusieurs fichiers bougent. Le handoff remet ces détails au premier plan.

Cas d’usage 3 : /release pour préparer, pas pour publier

Les commandes de release doivent rester prudentes. Le but n’est pas que Claude publie à votre place. Le but est de rassembler le contexte, préparer les notes, lister les blocages et laisser la décision finale à un humain.

Ce modèle utilise des arguments nommés. La documentation actuelle décrit arguments comme des noms associés aux arguments positionnels; ici le premier argument devient $version.

---
description: Prepare a release checklist and changelog draft without publishing.
argument-hint: [version]
arguments: [version]
disable-model-invocation: true
---

Prepare release $version.

Allowed work:
1. Inspect the current diff, package metadata, and changelog
2. Draft a changelog section for $version
3. Suggest verification commands
4. List release blockers and rollback notes
5. Propose a commit message

Safety rules:
- Do not run git push
- Do not publish packages
- Do not deploy to production
- Do not delete files
- Ask before changing version files

Output:
- Release summary
- Checklist
- Blockers
- Commands the user should run manually

C’est une commande de préparation, pas un bouton de publication. Si l’équipe automatise réellement la mise en production, placez cette responsabilité dans CI/CD avec approbations, journaux et règles de rollback explicites.

Arguments : commencer par $ARGUMENTS

Pour la plupart des commandes, $ARGUMENTS suffit. /handoff backend reviewer met backend reviewer dans $ARGUMENTS. La documentation actuelle prend aussi en charge $ARGUMENTS[0], $0 et les arguments nommés comme $issue ou $branch quand ils sont déclarés dans le frontmatter.

---
description: Prepare an issue-specific work plan.
argument-hint: [issue] [branch]
arguments: [issue, branch]
disable-model-invocation: true
---

Issue: $issue
Branch: $branch
All arguments: $ARGUMENTS

Create a plan that:
1. Restates the issue in plain language
2. Lists files to inspect first
3. Identifies likely tests
4. Names one thing that should not be changed

Mettez entre guillemets les arguments de plusieurs mots : /plan-issue "login redirect bug" fix-login. Méfiez-vous des anciens exemples qui supposent que $1 est le premier argument. La documentation actuelle décrit $0 comme le raccourci du premier argument positionnel.

Versioning et workflow de review

Traitez les Skills et Commands de projet comme du code. Ils influencent ce qui est relu, ce qui est oublié et ce que l’équipe appelle “terminé”. Une modification de .claude/skills/release-prep/SKILL.md doit apparaître dans une pull request, pas se cacher dans un diff de fonctionnalité.

Règle	Pourquoi c’est utile
Versionner .claude/skills/ dans Git	Savoir qui a changé le workflow et quand
Autoriser des PRs dédiées aux commandes	Ne pas mélanger règles de process et code applicatif
Lister les commandes dans README ou CLAUDE.md	Faciliter la découverte par les nouveaux membres
Interdire les actions destructrices dans le prompt	Éviter push, publish, deploy ou suppression accidentels
Nettoyer la liste chaque mois	Retirer les commandes obsolètes avant qu’elles gênent

Pour un déploiement d’équipe, associez cet article au guide de démarrage Claude Code, aux bonnes pratiques CLAUDE.md et au guide Claude Code Hooks.

Pièges et sécurité

La plus grande erreur est de croire qu’une commande personnalisée est sûre parce qu’elle est courte. Elle reste un prompt puissant. Si vous utilisez l’injection de contexte dynamique avec des backticks !, Claude Code exécute la commande shell et insère sa sortie avant que Claude lise le Skill. C’est pratique, mais il faut une limite stricte en lecture seule.

---
description: Collect read-only git context for release notes.
disable-model-invocation: true
---

Current status:
!`git status --short`

Recent commits:
!`git log --oneline -20`

Summarize the release notes from the information above.
Do not run write operations.

Limitez ces commandes à de l’inspection sûre comme git status et git log. N’incluez pas rm, git clean, git push, npm publish, curl ... | sh ni scripts qui touchent la production. Soyez aussi prudent avec allowed-tools : un accès Bash trop large peut réduire les confirmations là où l’équipe attendait une pause. Commencez avec des outils en lecture seule et ajoutez des droits seulement si le workflow l’exige vraiment.

Les échecs concrets sont faciles à prévoir. Un /review personnalisé entre en conflit avec un command intégré. Un Skill vit seulement dans le dossier personnel d’un développeur. Le corps devient trop long et consomme du contexte à chaque chargement. Un argument vide pousse Claude à scanner tout le dépôt. Un release inclut la publication. Tous viennent d’une automatisation trop ambitieuse. Commencez en lecture seule, gardez une cible réduite et intégrez la confirmation humaine.

CTA : transformer les modèles en routine d’équipe

Ces modèles n’ont de valeur que s’ils correspondent à votre dépôt. En solo, commencez par la cheatsheet Claude Code gratuite et gardez les patterns sûrs sous la main. Pour des modèles réutilisables de review, release et handoff, consultez les produits ClaudeCodeLab. Si votre équipe doit concevoir permissions, CLAUDE.md, review des Skills, limites CI et onboarding ensemble, utilisez la page formation et consultation Claude Code.

Après essai dans le workflow de Masa, le résultat était net : trois commandes suffisaient. /team-review, /handoff et /release-prep couvraient la majorité des répétitions sans transformer Claude Code en outil de déploiement risqué. Le gain principal venait de définir /release comme une commande qui rassemble des preuves pour une décision humaine, et non comme une commande qui publie. Les commandes slash personnalisées fonctionnent le mieux quand elles aident l’équipe à s’arrêter, vérifier et transmettre avec le même standard.