Commandes slash personnalisées dans Claude Code : créez les vôtres

Les commandes slash comme mémoire institutionnelle (ce que les équipes livrent vraiment)

Le meilleur usage que j'ai vu pour .claude/commands/, ce n'est pas la virtuosité, c'est la capture de connaissances tribales. Les threads sur r/ClaudeAI remontent toujours le même pattern : les commandes slash qui survivent à la revue et entrent dans le repo de l'équipe, ce sont celles qui encodent « comment on fait ici », pas celles qui enchaînent dix API Anthropic.

Les commandes qui rentabilisent régulièrement :

• →/review calée sur votre goût réel. Pas « review ce code », mais : « review ce diff contre nos conventions dans CLAUDE.md, signale tout ce qui viole nos règles no-mutation ou null-safety, suggère les cas de test qu'on demanderait normalement en code review ». Trente secondes de prompt engineering, rentabilisées à chaque PR.
• →/ship comme runbook de déploiement. Un prompt qui parcourt la même checklist qu'un ingénieur senior déroule dans sa tête : lint, tests, entrée dans le changelog, bump de version, git tag. Le départ d'un staff engineer vers un autre job, c'est le failure mode classique que ça évite.
• →/unstick pour récupérer du contexte. Quand une longue session part en vrille, une commande qui dit « résume ce qu'on voulait faire, ce qu'on a essayé, ce qui est cassé, et le minimum step suivant » vaut plus que personne ne l'admet. Les threads Reddit sur la dégradation des longues sessions convergent tous vers une variante de ça.

La référence officielle des commandes Claude Code documente $ARGUMENTS et le frontmatter, mais la sagesse communautaire est plus simple : committez le dossier .claude/commands/, revoyez les ajouts comme vous revoyez des règles eslint partagées, et supprimez toute commande que personne n'a lancée depuis trois mois.

Pourquoi des commandes personnalisées ?

Sans commandes personnalisées, vous vous répétez :

> Review this code following our style guide. Check for:
  - ESLint compliance
  - TypeScript strict mode compatibility
  - Our naming conventions from CONTRIBUTING.md
  - Performance patterns we use
  - Security vulnerabilities
  Run the tests after suggesting fixes.

Avec des commandes personnalisées :

> /code-review

Même résultat, zéro saisie. Et toute votre équipe utilise exactement le même processus.

Structure des fichiers de commande

Les commandes personnalisées sont des fichiers markdown dans .claude/commands/ :

• →project/.claude/commands/deploy.md
• →project/.claude/commands/code-review.md
• →project/.claude/commands/generate-docs.md

Commande basique

<!-- .claude/commands/hello.md -->
---
description: Say hello
---

Say hello to the user and introduce yourself.

Utilisation : /hello

Commande avec paramètres

<!-- .claude/commands/create-component.md -->
---
description: Create a React component
---

Create a new React component named $COMPONENT_NAME in the src/components folder.

Include:
- TypeScript types
- CSS module for styling
- Unit tests in __tests__ folder
- Storybook story

Utilisation : /create-component Button

Le $COMPONENT_NAME devient "Button".

Options du frontmatter

Le frontmatter YAML configure le comportement de la commande :

---
description: Short description shown in /help
allowed-tools: Tool1, Tool2(pattern)
---

description (obligatoire)

Apparaît dans la liste des commandes :

> /help

Custom Commands:
  /deploy         Deploy to staging environment
  /code-review    Review code with team standards
  /generate-docs  Generate API documentation

allowed-tools (optionnel)

Restreint les outils utilisables par la commande :

---
description: Safe documentation generator
allowed-tools: Read, Write(docs/**)
---

Generate documentation for the current project.

Cette commande ne peut que lire des fichiers et écrire dans le dossier docs.

Patterns d'outils :

Créer votre première commande

Étape 1 : Créer le dossier de commandes

mkdir -p .claude/commands

Étape 2 : Écrire le fichier de commande

<!-- .claude/commands/review.md -->
---
description: Review code following team standards
allowed-tools: Read, Bash(npm:test), Bash(npm:lint)
---

Review the current changes following our team standards:

## 1. Gather Changes
Run `git diff HEAD~1` to see recent changes.

## 2. Review Checklist

### Logic & Correctness
- [ ] Does the code do what it's supposed to?
- [ ] Are edge cases handled?
- [ ] Is error handling appropriate?

### Code Quality
- [ ] Is the code readable and well-organized?
- [ ] Are functions/methods appropriately sized?
- [ ] Is there unnecessary duplication?

### Testing
- [ ] Are new features tested?
- [ ] Do existing tests still pass?

### Security
- [ ] Is user input validated?
- [ ] Are there any exposed secrets?
- [ ] Are there SQL injection risks?

## 3. Run Verification
Run `npm test` and `npm run lint`.

## 4. Summary
Provide a summary with:
- Overall assessment (Approve/Request Changes)
- List of issues found
- Suggestions for improvement

Étape 3 : Utiliser la commande

> /review

Claude suit votre modèle à la lettre.

Substitution de paramètres

Les commandes prennent en charge les valeurs dynamiques avec $PARAMETER_NAME :

Paramètre unique

<!-- .claude/commands/test.md -->
---
description: Run tests for a specific module
---

Run tests for the $MODULE module:

1. Find all test files in src/$MODULE
2. Run `npm test -- --testPathPattern=$MODULE`
3. Summarize results

Utilisation :

> /test auth
> /test payments

Paramètres multiples

<!-- .claude/commands/migrate.md -->
---
description: Create database migration
---

Create a new database migration:

- Name: $MIGRATION_NAME
- Type: $TYPE (create_table, alter_table, add_index)

Generate the migration file and corresponding rollback.

Utilisation :

> /migrate add_user_avatar alter_table

Valeurs par défaut

<!-- .claude/commands/build.md -->
---
description: Build for environment
---

Build the project for $ENV environment.

$ENV defaults to "development" if not specified.

Variables de contexte

Les commandes peuvent référencer des informations contextuelles :

<!-- .claude/commands/explain.md -->
---
description: Explain selected code
---

Explain this code in detail:

$SELECTION

Cover:
- What it does
- How it works
- Why it's written this way

Exemples concrets de commandes

Commande de revue de code

<!-- .claude/commands/code-review.md -->
---
description: Comprehensive code review
allowed-tools: Read, Bash(git:diff*), Bash(npm:test), Bash(npm:lint)
---

Perform a thorough code review of recent changes.

## 1. Gather Changes
Run `git diff HEAD~1` to see recent changes.

## 2. Review Checklist

### Logic & Correctness
- [ ] Does the code do what it's supposed to?
- [ ] Are edge cases handled?
- [ ] Is error handling appropriate?

### Code Quality
- [ ] Is the code readable and well-organized?
- [ ] Are functions/methods appropriately sized?
- [ ] Is there unnecessary duplication?

### Testing
- [ ] Are new features tested?
- [ ] Do existing tests still pass?

### Security
- [ ] Is user input validated?
- [ ] Are there any exposed secrets?
- [ ] Are there SQL injection risks?

## 3. Run Verification
Run `npm test` and `npm run lint`.

## 4. Summary
Provide a summary with:
- Overall assessment (Approve/Request Changes)
- List of issues found
- Suggestions for improvement

Commande de déploiement

<!-- .claude/commands/deploy.md -->
---
description: Deploy to staging
allowed-tools: Bash(npm:*), Bash(git:*), Bash(docker:*)
---

Deploy the current branch to staging:

## Pre-flight Checks
1. Ensure all tests pass: `npm test`
2. Check for uncommitted changes: `git status`
3. Verify on correct branch

## Build
1. Run production build: `npm run build`
2. Build Docker image: `docker build -t app:staging .`

## Deploy
1. Push image: `docker push registry/app:staging`
2. Update staging: `kubectl rollout restart deployment/app -n staging`

## Verify
1. Wait for rollout: `kubectl rollout status deployment/app -n staging`
2. Check health endpoint
3. Run smoke tests

## Report
Summarize:
- Commit deployed
- Time taken
- Any issues encountered

Générateur d'endpoint API

<!-- .claude/commands/create-endpoint.md -->
---
description: Generate a new API endpoint
allowed-tools: Read, Write, Edit
---

Create a new REST API endpoint:

## Endpoint Details
- Resource: $RESOURCE
- Method: $METHOD (GET, POST, PUT, DELETE)

## Generate Files

### Route Handler
Create `src/routes/$RESOURCE.ts`:
- Express/Fastify route handler
- Input validation with Zod
- Error handling middleware

### Service Layer
Create `src/services/$RESOURCE.service.ts`:
- Business logic
- Database operations
- Proper error types

### Tests
Create `src/__tests__/$RESOURCE.test.ts`:
- Unit tests for service
- Integration tests for route
- Mock database calls

### Types
Add types to `src/types/$RESOURCE.ts`:
- Request/response interfaces
- Domain models

## Documentation
Update `docs/api.md` with new endpoint documentation.

Utilisation :

> /create-endpoint users POST
> /create-endpoint products GET

Générateur de documentation

<!-- .claude/commands/document.md -->
---
description: Generate documentation for a file
allowed-tools: Read, Write(docs/**)
---

Generate comprehensive documentation for $FILE:

## Analysis
1. Read the file and understand its purpose
2. Identify all exports (functions, classes, types)
3. Trace dependencies

## Documentation Output
Create `docs/$FILE.md` with:

### Overview
- File purpose
- When to use it
- Dependencies

### API Reference
For each export:
- Description
- Parameters with types
- Return value
- Example usage

### Examples
Provide 2-3 practical examples showing common use cases.

### Related
Link to related documentation files.

Commandes au niveau utilisateur

Les commandes personnelles se trouvent dans ~/.claude/commands/ :

• →~/.claude/commands/my-workflow.md
• →~/.claude/commands/quick-fix.md

Les commandes utilisateur sont disponibles dans tous les projets.

Commande de productivité personnelle

<!-- ~/.claude/commands/standup.md -->
---
description: Generate standup update
allowed-tools: Read, Bash(git:log*)
---

Generate my daily standup update:

## Yesterday
Run `git log --oneline --since="yesterday" --author="<my-email>"` and summarize what I worked on.

## Today
Based on:
- Open TODOs in the codebase
- Recent branch names
- Uncommitted changes

Suggest what I should focus on today.

## Blockers
Check for:
- Failing tests
- Merge conflicts
- Pending reviews

Format as:
---
**Yesterday:** <summary>
**Today:** <plan>
**Blockers:** <issues or "None">
---

Organisation des commandes

Par fonctionnalité

Organisez les commandes en sous-dossiers :

• →auth/ - add-oauth.md, update-session.md
• →api/ - create-endpoint.md, document-api.md
• →testing/ - unit-test.md, e2e-test.md

Les sous-dossiers deviennent des préfixes de commandes :

> /auth/add-oauth
> /api/create-endpoint

Par rôle

Organisez par rôle d'équipe :

• →dev/ - review.md, refactor.md
• →qa/ - test-plan.md, bug-report.md
• →devops/ - deploy.md, rollback.md

Partage des commandes en équipe

Contrôle de version

Committez .claude/commands/ dans votre dépôt :

git add .claude/commands/
git commit -m "Add team Claude Code commands"

Tout le monde obtient automatiquement les mêmes commandes.

Standards de commandes

Créez un README pour vos commandes :

<!-- .claude/commands/README.md -->
# Team Commands

## Development
- `/review` - Code review with team standards
- `/create-component` - Generate React component

## DevOps
- `/deploy staging` - Deploy to staging
- `/deploy production` - Deploy to production (requires approval)

## Testing
- `/test-unit` - Run unit tests
- `/test-e2e` - Run end-to-end tests

## Adding Commands
1. Create a markdown file in `.claude/commands/`
2. Follow the template in `_template.md`
3. Submit a PR for team review

Patterns avancés

Chaînage de commandes

Référencez d'autres commandes dans vos prompts :

<!-- .claude/commands/release.md -->
---
description: Full release process
---

Perform a complete release:

1. First, run the code review process (like /review)
2. Update version in package.json
3. Generate changelog from commits
4. Build for production (like /build production)
5. Create git tag
6. Deploy (like /deploy production)

Logique conditionnelle

Utilisez des prompts pour guider un comportement conditionnel :

<!-- .claude/commands/fix.md -->
---
description: Fix issues based on type
---

Fix the following issue: $ISSUE_TYPE

If $ISSUE_TYPE is "lint":
  - Run npm run lint:fix
  - Review and commit changes

If $ISSUE_TYPE is "test":
  - Run failing tests
  - Fix the failures
  - Verify all tests pass

If $ISSUE_TYPE is "type":
  - Run TypeScript compiler
  - Fix type errors
  - Ensure strict mode compliance

Commandes interactives

Les commandes peuvent demander plus d'informations :

<!-- .claude/commands/refactor.md -->
---
description: Interactive refactoring session
---

Start an interactive refactoring session.

First, ask the user:
1. What file or component to refactor?
2. What's the goal of the refactoring?
3. Are there any constraints?

Then:
1. Analyze the current code
2. Propose a refactoring plan
3. Wait for approval
4. Implement changes incrementally
5. Run tests after each change

Débogage des commandes

Tester votre commande

Lancez avec une sortie verbeuse :

claude --verbose
> /my-command

Problèmes courants

Commande introuvable :

• →Vérifiez que le fichier est dans .claude/commands/
• →Vérifiez que le nom de fichier se termine par .md
• →Assurez-vous que le frontmatter contient description

Les paramètres ne se substituent pas :

• →Utilisez le format exact : $PARAMETER_NAME
• →Vérifiez les fautes de frappe dans les noms de variables
• →Assurez-vous que les arguments sont fournis dans l'ordre

Erreurs de permissions :

• →Vérifiez les restrictions allowed-tools
• →Vérifiez les paramètres de permission du projet
• →Utilisez /permissions pour déboguer

Intégration avec d'autres fonctionnalités

Commandes + Hooks

Déclenchez des hooks depuis les commandes :

<!-- .claude/commands/safe-deploy.md -->
---
description: Deploy with safety hooks
allowed-tools: Bash(npm:*), Bash(git:*), Bash(docker:*)
---

Deploy to production with all safety checks.

This command relies on our PreToolUse hooks to:
- Validate deployment approvals
- Check for required tags
- Notify team via Slack

Voir Claude Code Hooks : automatisez votre workflow de développement.

Commandes + MCP

Utilisez les outils MCP dans les commandes :

<!-- .claude/commands/sync-issues.md -->
---
description: Sync GitHub issues
allowed-tools: mcp__github__*, Read, Write
---

Sync GitHub issues with local tracking:

1. Use GitHub MCP to fetch open issues
2. Update local TODO.md with issue list
3. Mark completed issues as done

Voir Model Context Protocol (MCP) pour Claude Code : guide complet.

Commandes + sous-agents

Créez des agents spécialisés :

<!-- .claude/commands/deep-analysis.md -->
---
description: Deep codebase analysis
---

Perform a deep analysis of the codebase:

Use the Explore sub-agent to:
1. Map all modules and dependencies
2. Identify architectural patterns
3. Find potential issues

Then synthesize findings into a report.

Voir Sous-agents Claude Code : orchestrer des tâches complexes.

En bref

1. →

   Les commandes sont des fichiers markdown : simples à créer, versionner et partager.

2. →

   Utilisez les paramètres pour la flexibilité : $PARAM_NAME rend les commandes réutilisables.

3. →

   Restreignez les outils pour la sécurité : allowed-tools limite ce que les commandes peuvent faire.

4. →

   Committez les commandes d'équipe : partagez via le contrôle de version pour la cohérence.

5. →

   Combinez avec d'autres fonctionnalités : les commandes s'intègrent avec les hooks, MCP et les sous-agents.

Construisez des prompts efficaces pour vos commandes

Les commandes personnalisées ne valent que par la qualité des prompts qu'elles contiennent. Apprenez à écrire des prompts qui obtiennent des résultats cohérents.

Dans notre Module 3, Les bases du prompt engineering, vous apprendrez :

• →Les principes fondamentaux du prompting efficace
• →Les techniques de structure et de clarté
• →L'affinage itératif des prompts
• →Les patterns courants et les anti-patterns

→ Explorer le Module 3 : Les bases du prompt engineering