Claude Code /simplify et /batch

Problème : Tu viens de terminer une fonctionnalité dans Claude Code. Les tests passent. Tu sais aussi que quelques fonctions se répètent, qu'un helper a été réinventé, et qu'il y a au moins une boucle qui fait plus de travail qu'il le faut. Revenir tout corriger à la main signifie relire chaque fichier touché, repérer les aspérités soi-même, et les corriger une à une. Livre en l'état et la dette technique te rattrape au prochain sprint. Aucune option n'est satisfaisante.

Victoire rapide : Juste après qu'une fonctionnalité atterrit, tape /simplify. Ça lance trois agents de revue en même temps. Un surveille la réutilisation de code. Un surveille la qualité. Un surveille l'efficacité. Ils mutualisent leurs notes, appliquent les correctifs, et te rendent un diff propre. Pas de prompt à écrire. Juste la commande.

# After implementing a feature
/simplify
 
# Focus on a specific concern
/simplify focus on memory efficiency

Nouveau sur Claude Code ? Le guide de démarrage couvre les bases. Tu as quelque chose de plus grand sur le feu, comme migrer tout un codebase d'un framework à un autre ou déployer un changement sur des dizaines de fichiers ? C'est là que /batch entre en jeu. Les deux commandes ont atterri dans Claude Code v2.1.63, et entre elles elles couvrent deux workflows qui nécessitaient auparavant un prompting multi-étapes soigné.

Ce Que Fait Claude Code /simplify

/simplify est une commande de nettoyage post-implémentation. Une fois que le code fonctionne, /simplify relit le diff et l'améliore.

La première étape est un appel à git diff (ou git diff HEAD) pour voir ce qui a bougé. Pas de changements git ? Il se replie sur les fichiers qui ont été touchés le plus récemment. À partir de là, trois agents de revue partent en parallèle. Chacun voit le diff complet :

Les trois tournent côte à côte. Une fois terminés, /simplify rassemble leurs notes, corrige chaque vrai problème directement, et laisse tomber discrètement tout ce qui ressemble à un faux positif. Tu obtiens un court résumé des correctifs, ou une note confirmant que le code était déjà en bon état.

Boris Cherny, le PM de Claude Code, l'a bien formulé : ces commandes groupées "automatisent une grande partie du travail qu'il fallait faire pour accompagner une pull request en production." /simplify est la passe de revue automatisée entre "ça marche" et "c'est prêt à merger."

Quand Utiliser /simplify

Le moment idéal, c'est juste après l'implémentation, avant d'ouvrir une PR :

• Après avoir terminé une fonctionnalité -- nettoie avant la revue
• Après un correctif de bug -- assure-toi que le correctif n'a pas introduit des raccourcis
• Après un prototype -- resserre le code expérimental que tu veux garder
• Avant une PR -- attrape les problèmes qu'un revieweur signalerait

Tu veux restreindre le focus ? Tu peux passer du texte optionnel :

/simplify focus on error handling
/simplify check for unnecessary dependencies
/simplify look at the database query patterns

C'est pratique quand tu sais qu'une zone est approximative mais que tu n'as pas envie d'écrire un prompt complet pour décrire le codebase. La commande sait déjà quels fichiers ont bougé.

Ce Que /simplify N'Est Pas

/simplify n'est pas un linter. Pas un formateur non plus. Il travaille à un niveau plus élevé que ça, regardant les choix architecturaux, la structure du code, et les choix d'algorithmes. ESLint et Biome restent dans la boucle. /simplify gère les préoccupations que ces outils ne peuvent pas attraper. Pour l'application de type validation, les hooks existent déjà.

Ce n'est pas non plus un outil de refactoring général. Son attention reste sur ce qui a changé récemment, pas sur le projet entier. Pour un changement à l'échelle du codebase, tu veux /batch.

Ce Que Fait Claude Code /batch

La commande /batch de Claude Code coordonne les grands changements dans ton projet, en parallèle. L'interface utilisateur est délibérément simple. Rien qu'une description et quelques exemples d'utilisation :

/batch migrate from react to vue
/batch replace all uses of lodash with native equivalents
/batch add type annotations to all untyped function parameters

Tu dis ce qui doit changer. /batch le confie à un agent d'orchestration plus profond qui fait la recherche, la décomposition, l'exécution, et la création de PR. Sous le capot, l'orchestrateur tourne une boucle en trois phases.

Phase 1 -- Recherche et Plan. L'orchestrateur passe en mode plan. Il lance des agents Explore pour tracer chaque fichier, pattern et site d'appel que l'instruction touche. À partir de là, il décompose le travail en 5 à 30 unités autonomes, dimensionnées par rapport au codebase et au changement. Chaque unité doit être implémentable seule dans un worktree, et mergeable seule sans attendre qu'une autre unité atterrisse en premier. L'orchestrateur élabore aussi une recette de vérification de bout en bout, que ce soit de l'automatisation navigateur, un test CLI, ou ta suite de tests existante. S'il ne sait pas comment vérifier le travail, il s'arrête et te demande.

Phase 2 -- Lancer les Workers. Une fois que tu approuves le plan, l'orchestrateur envoie un agent en arrière-plan par unité. Tous partent dans un seul bloc de messages, donc le parallélisme est réel. Chaque agent tourne avec isolation: "worktree" pour un worktree git propre. Le prompt de chaque agent est autonome : l'objectif global, la tâche spécifique, et les conventions du codebase recueillies pendant la recherche. Il porte aussi la recette de test de bout en bout et les instructions du worker. Après avoir écrit le code, chaque worker lance /simplify sur son propre diff, lance la suite de tests, commit, push, et ouvre une PR avec gh pr create.

Phase 3 -- Suivre l'Avancement. L'orchestrateur affiche un tableau de statut et continue de le mettre à jour au fur et à mesure que les agents terminent, extrayant les URLs de PR de la sortie de chaque worker. À la fin tu obtiens une ligne récapitulative comme "22/24 unités atterries comme PRs."

L'isolation par worktree, c'est ce qui fait fonctionner tout ça. Chaque agent a sa propre branche et sa propre copie de travail, ce qui signifie qu'aucun agent ne peut marcher sur les pieds d'un autre. Les conflits de merge n'apparaissent jamais. Chaque unité reste indépendamment testable et revoyable.

# Large-scale migration
/batch migrate src/ from Solid to React
 
# Pattern application
/batch add input validation to all API endpoints
 
# Convention enforcement
/batch rename all database columns from camelCase to snake_case
 
# Dependency update
/batch update all axios calls to use the new fetch wrapper

L'Étape de Plan

Avant qu'un seul fichier change, /batch expose le plan. Tu vois chaque unité de travail, quels fichiers il prévoit de toucher, et en quoi consiste le changement. Rien ne tourne jusqu'à ce que tu l'approuves.

C'est ce qui rend /batch prévisible. Tu ne confies pas ton projet à un processus autonome en croisant les doigts. La décomposition est visible. Tu vérifies qu'elle a du sens. Puis tu le lâches.

Si le plan est à côté (peut-être qu'il a manqué des fichiers, peut-être qu'il a mal groupé les choses), tu lui dis de s'ajuster avant que l'exécution commence. C'est le même esprit que les modes de planification pour les tâches individuelles, seulement mis à l'échelle du repo entier.

Prérequis

/batch a besoin d'un dépôt git. Sans exception. Chaque unité d'agent tourne dans son propre worktree git, et chacune ouvre une pull request à la fin. En dehors d'un dépôt git, /batch refuse de démarrer.

La règle de worktree, c'est aussi ce qui garde tes changements en sécurité. Le travail de chaque agent est sur sa propre branche. Si une unité rate ou produit du mauvais code, les autres continuent. Les bonnes PRs sont mergées. Les mauvaises sont jetées.

Quand Utiliser /batch

/batch est fait pour le travail qui se parallélise proprement. C'est-à-dire des dizaines ou des centaines de fichiers ont tous besoin du même genre de modification, et aucune modification ne dépend d'une autre.

Bons cas :

• Migrations de framework -- convertir des composants d'un framework à un autre
• Changements de contrat API -- mettre à jour tous les appelants quand une interface change
• Application de conventions -- appliquer des conventions de nommage, ajouter la gestion d'erreurs, ou standardiser des patterns dans le codebase
• Échanges de dépendances -- remplacer une bibliothèque par une autre sur tous les sites d'utilisation
• Génération de tests -- ajouter de la couverture de tests aux modules non testés

Mauvais cas :

• Changements étroitement couplés où le fichier A dépend de la nouvelle sortie du fichier B (ce ne sont pas des unités indépendantes)
• Refactoring exploratoire où tu ne connais pas encore l'état final
• Changements sur un seul fichier qui ne justifient pas de décomposition

Si le travail nécessite que des agents se coordonnent entre eux, disons que l'agent A crée un utilitaire partagé et que l'agent B doit l'importer, /batch n'est pas le bon outil. Les sessions Claude Code régulières ou les équipes d'agents gèrent ce genre de communication croisée.

/simplify vs /batch : Quand Utiliser Chaque Commande

Les deux commandes résolvent des problèmes différents à des échelles différentes. Framework de décision :

Une image mentale utile : dans Claude Code, /simplify est ton revieweur de code. /batch est ton équipe de migration.

Ils se complètent aussi par conception. Chaque worker /batch lance /simplify sur ses propres changements avant de commiter. Donc chaque PR qui sort de /batch a déjà passé la passe en trois agents. Pas de chaînage manuel. L'intégration est déjà câblée.

Exemples de Workflows Pratiques

Exemple 1 : Cycle de Développement de Fonctionnalité

Tu viens de câbler un nouveau flux d'authentification sur 4 fichiers :

# 1. Implement the feature (normal Claude Code session)
"Add JWT authentication with refresh tokens to the API"
 
# 2. Clean up with /simplify
/simplify
 
# 3. Focus on specific concerns if needed
/simplify focus on security patterns in the auth flow

Les trois agents de revue passent au peigne fin le code d'authentification pour détecter la logique de validation de token dupliquée, les problèmes de qualité comme les réponses d'erreur incohérentes, et les problèmes d'efficacité comme le décodage de token inutile.

Exemple 2 : Migration de Framework

Ton frontend a 45 composants de classe React qui doivent devenir des composants fonctionnels avec des hooks :

# 1. Describe the migration
/batch convert all React class components in src/components/ to functional components with hooks
 
# 2. Review the plan (batch shows 15 units of ~3 components each)
# 3. Approve
# 4. Each agent creates a PR with its batch of conversions
# 5. Review and merge PRs individually

Chaque PR tient seule pour la revue et le merge. Si une conversion devient délicate et nécessite une touche humaine, cette PR est mise de côté pendant que les autres continuent.

Exemple 3 : Standardisation d'API

Tes endpoints API utilisent des formats de réponse d'erreur incohérents :

/batch standardize all API error responses to use { error: string, code: number, details?: object } format

/batch trouve chaque endpoint, les regroupe en unités indépendantes (généralement par fichier de route ou domaine), et lâche chaque agent sur ses routes assignées. Chaque unité lance la suite de tests existante après les modifications, donc tu apprends vite si quelque chose a cassé.

Commandes Groupées vs. Commandes Slash Personnalisées

/simplify et /batch sont des commandes Claude Code groupées. Elles sont livrées avec chaque installation et fonctionnent dès le départ. Les commandes slash personnalisées sont l'autre variante : des prompts spécifiques au projet que tu écris toi-même, soit dans ta configuration CLAUDE.md, soit sous .claude/commands/, un peu comme les skills que tu définis pour ton propre workflow. Les commandes groupées sont maintenues par Anthropic et reçoivent des mises à jour à chaque release de Claude Code.

La différence compte parce que les commandes groupées atteignent des capacités internes que les commandes personnalisées ne peuvent pas. /batch peut lancer des agents dans des worktrees isolés et ouvrir des PRs automatiquement. /simplify peut déclencher son pipeline de revue en trois agents sans que tu écrives une seule ligne de colle d'orchestration.

Cela dit, les deux côtés se complètent. Les commandes personnalisées possèdent les éléments spécifiques au projet (ton processus de déploiement, tes conventions de tests, tes patterns de génération de code). Les commandes groupées possèdent les éléments universels (revue de code, modifications à l'échelle du codebase) qui s'appliquent à n'importe quel projet.

Tu as construit tes propres workflows de sous-agents qui assemblent manuellement une passe de revue multi-agents ? /simplify pourrait les remplacer complètement. Tu écrivais des scripts pour appliquer des modifications répétitives sur des fichiers ? /batch est la version native Claude de ce script.

Conseils pour Utiliser /simplify et /batch Efficacement

Lance /simplify avant chaque PR. Fais-en une habitude. La passe en trois agents attrape des choses que tu rateras après des heures de travail tête baissée. En pratique, /simplify remonte régulièrement 3 à 5 problèmes par branche de fonctionnalité qui auraient autrement remonté pendant la revue de code. L'agent d'efficacité est particulièrement fort pour attraper les itérations gaspillées et les opportunités de concurrence manquées.

Sois spécifique avec les descriptions /batch. "Mettre à jour le codebase" est trop vague. "Remplacer toutes les imports moment.js par dayjs, en mettant à jour les appels API pour correspondre à la syntaxe de dayjs" donne au planificateur assez de contexte pour décomposer le travail correctement.

Vérifie soigneusement le plan /batch. L'étape de décomposition est là où la plupart des problèmes apparaissent. Si une unité couvre trop de fichiers ou mélange des changements indépendants, demande un découpage différent avant d'approuver.

Utilise le texte de focus optionnel de /simplify. Quand tu sais qu'une zone est approximative, peut-être parce que tu as pris un raccourci pendant le prototypage, pointe /simplify directement dessus. Une revue ciblée donne de meilleurs résultats qu'un balayage générique.

Combine /batch avec ta suite de tests. Chaque agent /batch lance les tests après avoir édité. Assure-toi que ces tests attrapent vraiment les régressions. Des tests faibles signifient que les agents /batch vont "passer" du code cassé.

FAQ

Est-ce que /simplify modifie les fichiers automatiquement ?

Oui. /simplify écrit les correctifs directement dans ta copie de travail. Revois-les avec git diff avant de commiter. Mauvais correctif ? git checkout le fichier pour l'annuler.

Que se passe-t-il si un worker /batch échoue ?

Un worker qui échoue n'entraîne pas les autres avec lui. Chacun tourne dans son propre worktree git, sur sa propre branche. L'échec apparaît dans le tableau de statut, et tu réessaies cette unité ou tu la prends en main. Les PRs déjà atterries ne sont pas touchées.

Quelle version de Claude Code livre ces commandes ?

/simplify et /batch ont été livrés dans Claude Code v2.1.63. Lance claude --version pour vérifier. Sur une ancienne version, claude update les télécharge.

Est-ce que /batch gère les monorepos ?

Oui. /batch fonctionne dans n'importe quel dépôt git. Dans un monorepo, sois spécifique sur les packages ou répertoires à cibler dans ta description pour que le planificateur décompose le travail correctement.

En quoi /simplify est-il différent d'un linter ?

Les linters attrapent les problèmes de syntaxe et de style. /simplify attrape les problèmes architecturaux : logique dupliquée, abstractions manquées, inefficacités de performance, et patterns qu'un revieweur humain signalerait. Ils couvrent des couches différentes.

Prochaines Étapes

• Lis sur les git worktrees dans Claude Code pour comprendre le modèle d'isolation que /batch utilise
• Vois comment /simplify et /batch s'inscrivent dans le système complet de commandes slash du mode interactif, y compris les contrôles de session, les raccourcis clavier, et les questions de côté /btw
• Apprends comment les équipes d'agents fonctionnent pour les tâches multi-agents coordonnées que /batch ne peut pas gérer
• Explore les commandes slash personnalisées pour construire des workflows spécifiques au projet à côté de ces commandes groupées
• Consulte les meilleures pratiques de sous-agents pour concevoir tes propres patterns multi-agents
• Revois le guide des boucles de feedback pour intégrer des cycles de revue dans ton processus de développement
• Vois le changelog complet v2.1.63 pour tout ce qui a été livré avec ces commandes
• Besoin d'installer ou de mettre à jour Claude Code ? Le guide d'installation couvre la configuration sur chaque plateforme, y compris les commandes d'installation en une ligne

/simplify et /batch montrent où se dirige Claude Code : des workflows multi-agents groupés qui gèrent des patterns d'ingénierie courants dès le départ. Tu continues de revoir chaque diff. Tu continues d'approuver chaque plan. Mais le travail d'orchestration, le lancement des agents en parallèle, la gestion des worktrees, l'agrégation des résultats, n'est plus quelque chose que tu câbles toi-même. Attends-toi à d'autres commandes groupées dans cette veine au fur et à mesure que la plateforme mûrit.

Tu veux un framework de développement avec orchestration d'agents pré-construite, des commandes slash personnalisées, et des patterns multi-agents qui cohabitent avec ces commandes groupées ? Le ClaudeFast Code Kit est livré avec 18 agents spécialisés et un pipeline conçu exactement pour ce type de workflow.