Voyez les instructions de projet comme un exercice de signalement.
Qu’est-ce que votre agent doit savoir pour éviter un incident ? Souvent, tout se joue sur une seule ligne stupide, comme lui dire où se trouvent les sauvegardes et ce que ça implique pour la prod.
Cette seule ligne aurait pu éviter trois des catastrophes de vibe coding du CEO cette année. Toutes dues au même problème.
Voyez l’AGENTS.md comme des commentaires de code, mais consolidés. Pas le quoi, le pourquoi. Dès que vous commencez à décrire des choses facilement déductibles de la structure de votre repo, vous perdez votre temps et vos tokens.
Les standards et pratiques de code sont importants.
Quelles preuves sont requises, le cas échéant, pour un ticket ou une PR.
Le fait que vous vouliez putain de diagrammes Mermaid pour tout changement de design majeur dans vos demandes de fonctionnalités, parce que... c’est super utile.
Une skill doit gérer ceci : c’est un outil ou une pratique spécifique à un outil pour une situation qui sort de votre distribution, et la meilleure façon de s’en sortir.
Dans les deux cas, essayez de garder ça propre, lisible et concis, avec le moins de mots possible et le minimum de logique computationnelle que vous puissiez mobiliser.
Dire quelque chose comme We love uncle bob on our coding team, and strictly adhere to the principles of decoupling, SOLID, and self documenting code. CRAP everything at mid tolerances to reduce cyclomatic complexity. a sa place dans votre AGENTS.md et c’est bien plus simple que de claquer 10 000 tokens à expliquer les mêmes concepts.
C’est ce qu’on appelle un prior précalculé.
Quelque chose que la machine sait, mais qu’elle ne sait peut-être pas appliquer au projet ou au repo actuel.
Les priors précalculés sont sympas parce qu’un prior reste un prior, peu importe le domaine d’où il vient.
Write this app like an early Stephen King novel produira un changement dans votre style de code et de documentation. Peut-être pas un bon, mais vous voyez l’idée.
En fait, on peut tester la capacité de généralisation d’un modèle en évaluant s’il se contente de narrer ou s’il produit une différence tangible dans le rendu en faisant ça.
Typiquement, Claude et Astra intègrent ce genre de choses en profondeur, alors que Grok écrira dans le même style de code tout en vous pondant une narration de commentaires de classe mondiale.
Grok est plus divertissant, mais son biais pour la « correction » est un énorme problème pour la pensée créative sur des tâches de code, et je me demande s’il ne fait pas de l’overfitting dans des situations réelles à cause de ça.
Mais le point, c’est qu’on peut généralement empiler des priors à travers un domaine connexe, tant qu’on fait attention à ne pas créer d’ambiguïté en le faisant.
Un exemple de skill serait : voici comment utiliser l’API du registre de cookies. Le but de l’outil est de suivre vos progrès en cookies et friandises diverses. Voici la spec de l’API. Voici les pièges courants.
Si votre agent utilise un système téléphonique complexe, interagit avec un outil SDD, ou n’importe quoi de plus gros qu’une boîte à chaussures, c’est là qu’on crée une skill.