Modes personnalisés : code review, deploy, lint

Créer des modes adaptés à votre workflow

La leçon sur les modes unifiés vous a présenté le concept ; il est temps de le mettre à l’épreuve. Nous allons construire trois modes personnalisés qui couvrent des besoins récurrents de tout développeur : la revue de code, le déploiement et le linting. Chacun est un fichier .toml déposé dans ~/.vibe/agents/, avec un prompt système taillé sur mesure. Ce qui distingue ces trois modes n’est pas tant leur prompt que le triplet safety / auto_approve / enabled_tools : c’est lui qui décide de ce que Vibe peut toucher, et donc de ce que vous risquez.

Un relecteur qui ne peut rien casser

Le mode code review transforme Vibe en un relecteur exigeant qui analyse la qualité, la sécurité et la maintenabilité de votre code. Comme il ne fait que lire, il est déclaré safe avec auto_approve = true : aucune confirmation ne vous sera demandée, puisque aucun fichier ne sera modifié. La liste d’outils confirme cette promesse — ni write_file, ni edit_file, ni bash.

# ~/.vibe/agents/review.toml
display_name = "Code Review"
description = "Revue de code approfondie : sécurité, performance, maintenabilité."

safety = "safe"
auto_approve = true
model = "mistral-large-latest"

system_prompt = """
Vous êtes un senior developer en mode revue de code.

Processus :
1. Lire les fichiers modifiés (git diff ou fichiers spécifiés)
2. Analyser chaque changement selon 4 axes :
   - Sécurité (injection, XSS, CSRF, secrets exposés)
   - Performance (N+1, boucles imbriquées, mémoire)
   - Maintenabilité (nommage, complexité, duplication)
   - Correctness (logique, edge cases, types)

Format de sortie :
## 🔴 Critiques (à corriger avant merge)
## 🟡 Avertissements (à corriger rapidement)
## 🟢 Suggestions (améliorations optionnelles)

Pour chaque point : fichier, ligne, problème, correction proposée.
"""

enabled_tools = [
  "read_file",
  "grep",
  "list_dir"
]

Le format de sortie imposé dans le prompt n’est pas cosmétique : il vous permet de trier en un coup d’œil ce qui bloque une pull request et ce qui peut attendre. Vous lancez le mode, puis vous lui donnez soit une consigne libre, soit un périmètre précis.

vibe --agent review
# > Analyse les fichiers modifiés dans la branche courante
# > /review src/api/

Un déploiement qui refuse d’improviser

Le mode deploy est l’exact opposé. Il touche à la production, il est donc déclaré destructive avec auto_approve = false : chaque action passe par votre validation. Toute la valeur du mode tient dans la séquence figée de son prompt, et surtout dans ses conditions d’arrêt. Un déploiement improvisé un vendredi soir commence toujours par une étape sautée ; ici, un test rouge arrête tout.

# ~/.vibe/agents/deploy.toml
display_name = "Deploy"
description = "Déploiement contrôlé avec tests, build et vérification."

safety = "destructive"
auto_approve = false
model = "codestral-latest"

system_prompt = """
Vous êtes en mode déploiement. Suivez cette séquence SANS EXCEPTION :

1. VÉRIFIER — git status propre, pas de fichiers non commités
2. TESTER — exécuter la suite de tests complète
3. BUILDER — build de production
4. VALIDER — vérifier le build (taille, erreurs, warnings)
5. CONFIRMER — demander à l'utilisateur avant de continuer
6. DÉPLOYER — exécuter la commande de déploiement
7. VÉRIFIER — confirmer que le service répond correctement

Si une étape échoue : STOP. Expliquez le problème et proposez une solution.
Ne jamais déployer si les tests échouent.
Ne jamais déployer si le build contient des warnings critiques.
"""

enabled_tools = [
  "read_file",
  "write_file",
  "bash",
  "grep",
  "list_dir",
  "ask_user_question"
]

La présence de ask_user_question dans les outils est indispensable : sans lui, l’étape 5 serait un vœu pieux, l’agent n’ayant aucun moyen technique de vous interroger.

vibe --agent deploy
# > Suit la séquence test → build → deploy → vérification

Un nettoyage automatique mais discipliné

Entre les deux se place le mode lint, qui automatise le formatage, les conventions et le tri des imports. Il modifie des fichiers, donc neutral, mais ses corrections sont mécaniques et réversibles par Git : auto_approve = true évite de vous faire cliquer cinquante fois. Les trois règles de fin de prompt sont ce qui l’empêche de déraper — un agent laissé libre a vite fait d’installer Biome dans un projet qui vit très bien avec ESLint.

# ~/.vibe/agents/lint.toml
display_name = "Lint & Fix"
description = "Nettoyage automatique : lint, format, imports, conventions."

safety = "neutral"
auto_approve = true
model = "codestral-latest"

system_prompt = """
Vous êtes en mode nettoyage de code.

Tâches :
1. Détecter les outils du projet (ESLint, Biome, Prettier, oxlint)
2. Exécuter le lint avec auto-fix
3. Exécuter le formatage
4. Trier et nettoyer les imports
5. Supprimer le code mort détectable
6. Rapporter les erreurs non corrigibles automatiquement

Règles :
- Utiliser les outils déjà configurés dans le projet
- Ne pas modifier la configuration des outils
- Ne pas ajouter de nouveaux outils sans demander
"""

enabled_tools = [
  "read_file",
  "edit_file",
  "bash",
  "grep",
  "list_dir"
]

Deux modes de plus, et une règle de rangement

Le même raisonnement se transpose à d’autres besoins. Un mode documentation reste neutral mais garde auto_approve = false, car générer des fichiers dans un dépôt mérite un regard avant écriture.

# ~/.vibe/agents/docs.toml
display_name = "Documentation"
description = "Génère et met à jour la documentation technique."
safety = "neutral"
auto_approve = false
model = "mistral-large-latest"

system_prompt = """
Générez de la documentation technique. Pour chaque fichier :
- JSDoc/TSDoc pour les fonctions publiques
- README avec exemples d'utilisation
- Variables d'environnement documentées
- Schémas d'API si applicable
"""

enabled_tools = ["read_file", "write_file", "edit_file", "grep", "list_dir"]

Un mode migration, lui, rejoint deploy dans la catégorie destructive : une migration de schéma mal jouée ne se rattrape pas avec un git revert, d’où l’exigence d’un script de rollback systématique.

# ~/.vibe/agents/migrate.toml
display_name = "Migration"
description = "Gère les migrations de base de données et de dépendances."
safety = "destructive"
auto_approve = false
model = "mistral-large-latest"

system_prompt = """
Vous gérez les migrations. Règles absolues :
- Toujours générer un script de rollback
- Tester la migration sur une copie avant production
- Documenter chaque changement de schéma
"""

enabled_tools = ["read_file", "write_file", "bash", "grep", "ask_user_question"]

Rangez enfin votre répertoire d’agents de façon à ce que la criticité se lise dans l’arborescence elle-même. Quand vous basculez de mode au clavier en pleine session, vous devez savoir sans réfléchir si le mode que vous venez d’activer peut écrire sur votre disque.

~/.vibe/agents/
├── review.toml          # safe — lecture seule
├── lint.toml            # neutral — modifications contrôlées
├── docs.toml            # neutral — génération de fichiers
├── deploy.toml          # destructive — avec confirmation
└── migrate.toml         # destructive — avec confirmation

Points clés à retenir

• Chaque mode est un fichier .toml dans ~/.vibe/agents/ conçu pour un workflow spécifique
• Le mode review est safe + auto_approve = true — il ne peut que lire
• Le mode deploy est destructive + auto_approve = false — il demande confirmation
• Le mode lint est neutral + auto_approve = true — il corrige automatiquement
• Ajustez le model selon la complexité de la tâche
• Le system_prompt est la clé — soyez précis sur la séquence et les règles