Des agents qui suivent les règles

Au début, la plupart de mon travail avec les coding agents, c'était du prompting. J'écrivais un long message, je listais ce que je voulais et j'espérais que ça tienne. Ça tenait pour une tâche. La session suivante repartait de zéro, et l'agent refaisait les mêmes erreurs.

Alors j'ai arrêté d'écrire des prompts et j'ai commencé à écrire un contrat. Il vit dans un repo public qui s'appelle Skills. Ce post explique ce qu'il y a dedans et pourquoi ça marche mieux que de demander poliment.

Ce que contient le pack

Skills a deux parties.

• Un fichier AGENTS.md que chaque harness charge à chaque tour. Il est court, et il sert d'index.
• Un ensemble de skills, chacun dans un dossier avec un SKILL.md : build, review, vérification, écriture de ticket, investigation, et quelques autres.

Ça s'installe comme plugin pour Claude Code, Cursor et Codex, et les mêmes dossiers de skills servent aux trois. Pas de règles juste pour Cursor, pas de règles juste pour Claude. Une seule copie des règles, trois endroits qui la lisent.

Pourquoi un contrat bat un prompt

Un prompt, c'est une demande ponctuelle. Un contrat, c'est du contexte permanent. Il passe avant les mauvaises habitudes de l'agent, et il s'applique même quand je n'en parle jamais.

La deuxième différence, c'est la taille. Un prompt qui essaie de contenir toutes mes préférences devient un mur de texte que l'agent survole. Le contrat, lui, contient presque aucun détail. Il contient des pointeurs, et chaque pointeur dit quand le suivre.

Les mécanismes qui comptent

Du routage selon la demande

La table des skills dans AGENTS.md associe ce que je demande au seul skill qui en est responsable. Je demande une feature, ça ouvre le skill de build. Je demande une review, ça ouvre le skill de review. Je demande un ticket, ça ouvre le skill de ticket. L'agent n'improvise pas une version plus faible d'un workflow qui existe déjà.

Quand l'agent ne sait pas lequel s'applique, il y a un skill routeur, ask-gabriel, qui sert de carte.

Des règles ouvertes au moment où elles comptent

Chaque règle du contrat, c'est une ligne en gras plus un déclencheur. Le déclencheur nomme le moment où il faut ouvrir le fichier. Voici la ligne pour les tests :

3. **No tests unless the user accepted that test.** About to create or extend a test? Open `rules/no-unrequested-tests.md`. Skip it and you add tests the user has to delete.

L'agent n'a pas besoin de garder toute la politique de tests en tête pendant la session. Il a juste besoin de remarquer le moment, d'ouvrir le fichier et de lire le détail à ce moment-là. Le même pattern couvre la qualité du code, la structure du code, la planification, le shipping et le style d'écriture. Une table dans le contrat liste chaque moment à côté du fichier à ouvrir.

Des tests seulement avec mon accord

Les agents adorent écrire des tests que personne n'a demandés. Ils répètent le code, ils gonflent le diff, et je finis par les supprimer. Dans ce pack, le skill de build par défaut propose des tests une fois le plan réglé, et il écrit seulement ceux que j'accepte. Je peux tous les refuser, et le travail continue sans eux. Rouler les tests existants, c'est toujours correct. Créer de nouveaux tests demande mon oui.

Des réponses en langage simple

Le pack a une règle de style pour les réponses dans le chat. Des mots ordinaires, pas d'étiquettes faites juste d'acronymes, et pas de questions dont le repo a déjà la réponse. Ça a l'air petit, mais ça change à quel point le résultat est facile à reviewer. Si je ne comprends pas ce que l'agent a fait, je ne peux pas attraper ce qu'il a mal fait.

Une vérification proportionnelle au risque

La vérification suit ce qui a changé. Un petit fix de bug a droit à une reproduction et aux tests pertinents. Une infrastructure partagée ou l'authentification peuvent justifier des vérifications plus larges. Le rapport final dit ce qui a vraiment roulé et ce qui n'a pas roulé. Les vérifications prévues ne comptent pas comme preuve.

Ce que j'ai appris

Trois choses.

1. Mieux vaut court que complet. Le contrat est un index. Le détail vit dans des fichiers que l'agent ouvre au besoin.
2. Nomme le déclencheur. Une règle qui dit « écris du bon code » ne fait rien. Une règle qui dit « sur le point d'ajouter un fichier, ouvre celui-ci » se fait suivre.
3. Une seule source de vérité. J'ai déjà collé des standards dans plusieurs outils. Ils ont dérivé. Maintenant il y a un seul AGENTS.md, et le pack te dit de supprimer les anciens copier-coller.

Le contrat n'est pas parfait. Les agents sautent encore une étape de temps en temps. La différence, c'est qu'une étape sautée est maintenant une infraction visible à une règle écrite, pas une vague déception. Je peux pointer la ligne, et je peux corriger la ligne.

Si tu veux l'essayer, les étapes d'installation sont dans le README du repo. Commence par le skill routeur si tu ne sais pas par où partir.