4 commandes slash Claude Code que j'utilise sur chaque projet

Quand on commence à utiliser Claude Code, on finit par taper les mêmes instructions encore et encore. "Fais une revue de sécurité." "Configure le SFTP." "Crée le CLAUDE.md avec la stack PHP/Vue." Après la dixième fois, ça lasse.

Les commandes slash personnalisées règlent ce problème. Ce sont des fichiers Markdown que vous écrivez une fois, et qui deviennent des raccourcis réutilisables sur tous vos projets.

Voici les 4 que j'utilise systématiquement et comment les créer vous-même.

Comment fonctionnent les commandes slash ?

Une commande slash, c'est un fichier .md dans le dossier ~/.claude/commands/. Le nom du fichier devient la commande.

~/.claude/commands/
├── setup-project.md   → /setup-project
├── review.md          → /review
├── sftp.md            → /sftp
└── optimize.md        → /optimize

À l'intérieur, vous écrivez des instructions en langage naturel, exactement comme vous les taperies dans le chat. Claude les exécute quand vous appelez la commande.

Ces commandes sont globales : elles fonctionnent dans n'importe quel projet, pas seulement celui où vous les avez créées.

/setup-project, Le bootstrapper de projet

Problème résolu : démarrer un projet from scratch prend du temps. Créer le CLAUDE.md, le .gitignore, le .env.example, la checklist de sécurité... autant de fichiers à ne pas oublier.

/setup-project commence par poser 5 questions :

• Nom et description courte du projet
• Stack : PHP, Vue.js, Tailwind, MySQL, Supabase...
• Déploiement SFTP : oui ou non
• Projet vierge ou code existant

Puis il génère automatiquement 5 fichiers prêts à l'emploi :

Un projet correctement configuré en 2 minutes au lieu de 20. Et surtout, Claude connaît votre stack dès le départ, il ne vous proposera pas du console.log dans du code PHP.

/review, L'audit sécurité avant chaque déploiement

Problème résolu : avant une mise en prod, on vérifie mentalement une dizaine de choses. On en oublie toujours une.

Cette commande inspecte les fichiers modifiés récemment et passe en revue ~15 catégories de sécurité :

• Injections SQL (requêtes préparées, pas de concaténation)
• XSS (échappement des outputs HTML)
• Authentification (RBAC, IDOR, accès horizontal et vertical)
• Secrets (aucun mot de passe en dur dans le code)
• Upload de fichiers (validation MIME, renommage automatique)
• Headers HTTP (CSP, HSTS, X-Frame-Options)
• Dépendances vulnérables

Le rapport est structuré en 3 niveaux clairs :

CRITIQUE  : Failles à corriger avant tout déploiement
IMPORTANT : Problèmes de qualité à corriger
SUGGESTION: Améliorations optionnelles

Un détail que j'apprécie : la commande est contextuelle. Si vous modifiez un fichier JS utilitaire, elle ne vous sort pas un rapport sur les headers HTTPS, elle se concentre sur ce qui est pertinent.

Avant tout git push, /review. C'est devenu un réflexe.

/sftp, La config de déploiement en 2 minutes

Problème résolu : configurer le plugin SFTP de VSCode (Natizyskunk) à la main est fastidieux, et on oublie toujours d'exclure certains fichiers sensibles.

/sftp pose les questions essentielles, host, port, username, chemin distant et génère .vscode/sftp.json avec les bons paramètres :

{
    "host": "ftp.monsite.com",
    "uploadOnSave": true,
    "ignore": [
        ".env",
        ".git",
        "CLAUDE.md",
        "node_modules"
    ]
}

Deux décisions importantes dans sa conception :

1. Il ne demande jamais le mot de passe, c'est délégué au plugin, pour ne jamais écrire de credential en clair dans un fichier.
2. autoDelete: false est volontaire, on ne supprime jamais automatiquement des fichiers sur le serveur.

Et à la fin, il vérifie que .vscode/sftp.json est bien dans le .gitignore. Parce qu'un host + username qui se retrouve sur GitHub, ça arrive plus souvent qu'on ne croit.

/optimize, Le ménage de printemps des tokens

Problème résolu : avec le temps, les fichiers de configuration gonflent, se dupliquent, deviennent verbeux. Chaque token inutile ralentit Claude et coûte plus cher.

/optimize fait un audit en 3 étapes :

1. Audit du CLAUDE.md Il cherche les répétitions, les règles trop verbeuses, les sections obsolètes. Si votre CLAUDE.md contient deux fois la même règle reformulée différemment, il le signale et propose une version condensée.

2. Vérification des commandes projet Il regarde si vos commandes locales dupliquent ce qui est déjà dans le CLAUDE.md. Ce qui est redondant est suggéré à la suppression.

3. Rappel des habitudes économiques

Deux exemples concrets qui font une vraie différence :

❌ "Explique-moi ce fichier de 800 lignes" ✅ "Explique-moi la fonction parseMarkdown() ligne 47"

❌ Copier-coller du code dans le prompt ✅ Référencer le fichier directement, Claude sait le lire

Un CLAUDE.md bien entretenu, c'est des réponses plus rapides et une meilleure cohérence sur la durée du projet.

Comment créer vos propres commandes

La structure est minimaliste. Un fichier Markdown dans le bon dossier :

~/.claude/commands/ma-commande.md

À l'intérieur, des instructions en langage naturel :

# Ma commande

Demande d'abord à l'utilisateur X.
Puis génère le fichier Y avec ce contenu.
Si la réponse est Z, fais plutôt W.

Quelques idées selon votre contexte :

• /deploy, pipeline de déploiement complet adapté à votre hébergeur
• /test, génération de tests unitaires sur les fonctions modifiées
• /changelog, extraction des commits en changelog lisible pour un client
• /db-migration, vérification qu'une migration SQL est réversible

Le principe qui les unit

Ces 4 commandes ont un point commun : elles codifient ce que vous feriez de toute façon. La revue de sécurité, vous l'avez faite mentalement avant de déployer. Le SFTP, vous l'avez configuré à la main. La documentation du projet, vous l'avez écrite.

Les commandes slash ne remplacent pas votre jugement, elles l'encodent une fois pour ne plus avoir à le réinventer à chaque projet.

Vous voulez voir à quoi ressemblent ces fichiers en détail ou démarrer votre propre setup Claude Code ? Contactez-moi, je partage mes configurations volontiers.