Bonnes pratiques

De meilleurs résultats avec une intention claire, une bonne configuration de projet et le mode adapté à la tâche.

À faire / à éviter

À faire	À éviter
Être précis : symptôme, zone et contexte	Dire « corrige le bug » ou « améliore » sans contexte
Utiliser Plan pour les gros refactors, puis Agent pour implémenter	Passer directement à Agent pour de gros changements de conception
Lancer les barrières après les changements et en CI	Fusionner sans exécuter les barrières
Placer les normes dans AGENTS.md ou .midcore/rules	Ne compter que sur des instructions ponctuelles dans le chat
Verrouiller les contrats avant l’implémentation avec le compilateur	Coder avant que les contrats soient figés

Une intention précise

Plutôt que « corrige le bug », décrivez le symptôme et le contexte :

Bon : « Corriger le bug de connexion : écran vide après un mauvais mot de passe. Front dans apps/web. »
Faible : « Corrige le bug »

Indiquez fichiers, zones ou messages d’erreur quand vous les avez. L’agent réduit ainsi le périmètre et évite les changements hors sujet.

Choisir le bon mode

Mode	Quand l’utiliser
Agent	Implémentation, éditions multi-fichiers, correctifs avec changements de code
Plan	Conception, stratégie de migration, architecture ; sans édition
Debug	Analyse des pannes, plusieurs hypothèses, petits correctifs ciblés
Ask	Exploration, Q&R, documentation seulement ; pas de code

Plan pour les gros refactors et Agent pour l’exécution : le périmètre reste maîtrisé et on limite les retours en arrière.

Rédiger de bons AGENTS.md et règles

Placez les normes de code, bibliothèques préférées et « toujours lancer le lint avant commit » dans AGENTS.md ou .midcore/rules/. Des puces courtes et actionnables valent mieux que de longs textes. Voir Instructions et mémoire.

Les contrats d’abord

Avec le compilateur d’outcomes, verrouillez le périmètre et les contrats avant d’implémenter. Ne passez pas directement au code : les API et les evidences restent alignées et on évite la refonte. Voir Compilateur d’outcomes.

Exécuter les barrières régulièrement

Lancez midcore gates run en CI et avant les livraisons. Les evidences des barrières sont la preuve attendue pour l’audit et la conformité. Corrigez les échecs avant fusion.

Ajoutez une étape CI qui exécute midcore gates run (et éventuellement midcore agent « … » pour des tâches automatisées). Voir CI/CD pour des exemples de pipeline.

Dérive de périmètre

Si l’agent touche trop de fichiers hors sujet, précisez l’intention (fichiers ou zones) ou commencez par le mode Plan pour verrouiller le périmètre.

Vérifier après les éditions

Laissez l’agent lancer lint et tests après les changements lorsque l’environnement le permet. Corrigez les nouvelles erreurs tout de suite pour éviter l’accumulation. Utilisez Plan ou des tâches plus ciblées si l’agent introduit trop de régressions.

Points clés

Une intention claire (symptôme, zone, contexte) améliore le périmètre et limite les éditions hors sujet.
Le bon mode : Plan pour concevoir, Agent pour implémenter, Debug pour les pannes, Ask pour explorer.
Contrats d’abord, barrières souvent, vérification après édition pour éviter l’empilement d’erreurs.

Flux courants · Étendre Midcore · Fonctionnement de Midcore · CI/CD