Productivité avancée : combiner agents, skills et modes

L’écosystème complet

Vous maîtrisez maintenant les trois piliers de Mistral Vibe : les agents décident qui exécute, les skills décrivent quoi faire, les modes fixent dans quel contexte. Pris isolément, chacun apporte un gain modeste. C’est leur combinaison qui change la nature du travail — et cette leçon vous montre comment l’organiser en un environnement de développement professionnel cohérent.

Tout commence par le rangement. Ce qui vous suit d’un projet à l’autre vit dans ~/.vibe/ ; ce qui n’a de sens que pour un dépôt reste dans le dépôt. Cette séparation vous évite de traîner un skill de seed de base de données dans tous vos projets, et évite surtout qu’un collègue clone votre dépôt sans hériter des outils dont il a besoin.

~/.vibe/
├── agents/
│   ├── review.toml          # Mode revue de code (safe)
│   ├── dev.toml             # Mode développement (neutral)
│   ├── deploy.toml          # Mode déploiement (destructive)
│   └── ci-runner.toml       # Subagent CI (yolo, container only)
├── skills/
│   ├── code-review/SKILL.md
│   ├── test-gen/SKILL.md
│   ├── smart-commit/SKILL.md
│   ├── lint-fix/SKILL.md
│   └── db-migrate/SKILL.md
└── config.toml

mon-projet/.vibe/
├── skills/
│   ├── deploy-staging/SKILL.md    # Spécifique au projet
│   └── seed-database/SKILL.md    # Spécifique au projet
└── config.toml                    # Configuration locale

Une journée type

La matinée commence en lecture seule. Vous démarrez en mode plan, vous demandez ce qui a bougé depuis lundi, vous vous faites expliquer un module que vous n’avez pas touché depuis six mois — rien de tout cela ne modifie un fichier. Une fois le terrain reconnu, Shift+Tab vous fait basculer vers le mode review pour attaquer une pull request.

# Démarrer en mode plan (lecture seule)
vibe --agent plan

# Explorer les changements récents
> Quels fichiers ont été modifiés depuis lundi ?
> Analyse l'architecture du module src/api/

# Basculer vers le mode review
# Shift+Tab → review
> Revois les changements de la PR #42

Vient l’implémentation, qui exige un mode capable d’écrire. Vous décrivez ce que vous voulez, puis vous déléguez aux slash commands tout ce qui est mécanique : générer les tests du fichier que vous venez d’écrire, nettoyer le répertoire touché.

# Basculer vers le mode dev
# Shift+Tab → dev

> Implémente le endpoint POST /api/users avec validation Zod

# Utiliser les slash commands
/test-gen src/api/users.ts
/lint-fix src/api/

Avant de commiter, la même séquence revient chaque fois, ce qui est précisément la raison d’en avoir fait des commandes.

# Slash commands en séquence
/lint-fix src/
/code-review src/api/users.ts

# Commit intelligent
/smart-commit

Le déploiement, enfin, se fait dans un mode destructive où chaque étape passe par votre validation. Le changement de mode est ici une barrière de sécurité autant qu’un changement d’outillage.

# Basculer vers le mode deploy (destructive, confirmation requise)
# Shift+Tab → deploy

> Déploie sur staging
# Vibe suit la séquence : tests → build → deploy → vérification

Faire dialoguer agents et skills

Un agent peut connaître vos skills et vous les rappeler au bon moment. Il suffit de les mentionner dans son prompt système : l’agent ne les exécute pas à votre place, mais il vous suggère la commande pertinente juste après avoir produit du code, au moment exact où vous alliez l’oublier.

# ~/.vibe/agents/fullstack-dev.toml
display_name = "Fullstack Dev"
safety = "neutral"
auto_approve = false

system_prompt = """
Vous êtes un développeur fullstack.
Skills disponibles que vous pouvez suggérer à l'utilisateur :
- /test-gen pour les tests unitaires
- /lint-fix pour le nettoyage
- /smart-commit pour les commits
- /code-review pour la relecture

Après chaque implémentation, suggérez les skills pertinents.
"""

Les subagents, eux, prennent en charge une portion isolée du pipeline pendant que vous continuez à travailler. Un contrôle de sécurité en lecture seule est le cas d’école : il n’a besoin que de read_file et grep, ne peut donc rien casser, et tourne en parallèle sans vous interrompre.

# Subagent pour l'analyse de sécurité (tourne en parallèle)
display_name = "Security Check"
agent_type = "subagent"
safety = "safe"
auto_approve = true
system_prompt = """Analysez les fichiers pour les failles OWASP Top 10."""
enabled_tools = ["read_file", "grep"]

Trois enchaînements qui reviennent toujours

Le premier, « Explore → Plan → Execute », convient aux fonctionnalités nouvelles : vous explorez le codebase avec l’agent plan pour comprendre le contexte, vous demandez à Vibe de proposer un plan d’implémentation, puis vous exécutez ce plan avec l’agent dev ou accept-edits. Le deuxième, « Write → Review → Fix », s’applique au code que vous venez d’écrire : implémenter avec l’agent dev, relire avec /code-review, corriger les problèmes identifiés en repassant en dev. Le troisième, « Test → Commit → Deploy », ferme le cycle : /test-gen puis exécution des tests, /smart-commit pour un message conventionnel, agent deploy pour la mise en production avec vérification.

Deux niveaux de configuration

Le config.toml global déclare ce qui vous suit partout, y compris un répertoire de skills partagés en équipe — c’est ainsi qu’une convention de commit ou une checklist de revue cesse d’être une affaire personnelle.

# ~/.vibe/config.toml

# Skills activés globalement
enabled_skills = ["code-review", "test-gen", "lint-fix", "smart-commit"]

# Chemins de skills partagés en équipe
skill_paths = ["/home/equipe/vibe-skills"]

Le fichier local complète cet ensemble avec les skills propres au projet, et surtout retire ceux qui n’y ont pas leur place. Ce disabled_skills compte autant que l’activation : une auto-complétion encombrée de commandes hors sujet finit par ne plus être consultée.

# mon-projet/.vibe/config.toml

# Skills supplémentaires pour ce projet
enabled_skills = ["deploy-staging", "seed-database", "db-migrate"]

# Désactiver les skills non pertinents
disabled_skills = ["experimental-*"]

Reste à vérifier que tout cela produit un effet réel. Chronométrez votre temps de context-switch : passer d’une tâche à l’autre devrait prendre moins de cinq secondes avec Shift+Tab, sinon vos modes sont mal découpés. Comptez ensuite combien de fois par jour vos slash commands servent réellement — une commande jamais appelée en deux semaines est à supprimer ou à renommer. Regardez enfin combien de problèmes le mode review attrape avant le commit : c’est la mesure la plus parlante, puisqu’elle se compte en bugs qui n’ont jamais atteint la production.

Points clés à retenir

• Organisez vos agents par niveau de sécurité, vos skills par fonctionnalité
• Suivez le pattern “Explore → Plan → Execute” pour les nouvelles fonctionnalités
• Utilisez les slash commands pour les tâches répétitives
• Combinez agents globaux et skills locaux par projet
• Shift+Tab est votre raccourci le plus productif
• Mesurez et ajustez votre configuration régulièrement