En bref

  • Problème : les règles agent peuvent vite se disperser entre AGENTS.md, skills, hooks, scripts et mémoire de projet.
  • Ce que j’ai regardé : les surfaces Codex disponibles, les habitudes Project Pezzos et la première mise en skills des workflows article/lab.
  • Résultat : le découpage devient plus clair, mais je n’ai pas encore de preuve qu’il améliore le résultat final.
  • À retenir : juger le rangement des règles sur un diff réel, pas sur l’élégance du système.

Pourquoi je garde cette question

Le sujet intéressant autour des agents de code n’est pas « les agents vont tout changer ». Il est plus mécanique : comment laisser un agent avancer vite sans perdre les preuves, les checks et les limites qui permettent de reprendre la main.

Dans Project Pezzos, trois surfaces se superposent déjà :

  • AGENTS.md pour les contraintes locales du projet ;
  • des notes de travail pour les décisions et les reprises ;
  • des skills pour empaqueter des workflows réutilisables.

Le risque est de tout mettre partout. Une instruction utile à un projet précis n’a pas le même rôle qu’une méthode réutilisable, et un script de validation ne remplace pas une décision éditoriale ou technique.

Les repères que donnent les sources

Les docs officielles Codex Skills décrivent une skill comme un répertoire contenant un SKILL.md, avec la possibilité d’ajouter des scripts, références et assets. Le modèle pousse vers la progressive disclosure : le contexte lourd ne doit pas forcément être chargé avant d’être utile.

Les docs Codex local config documentent aussi des surfaces comme configuration, rules, hooks, AGENTS.md, MCP et skills. Cela confirme qu’un workflow Codex n’est pas seulement un prompt : il est fait de règles, d’outils et de contraintes locales.

OpenAI a publié des textes sur le Codex agent loop et sur le Codex harness. Ces sources sont utiles pour cadrer le vocabulaire, mais elles ne décident pas comment Project Pezzos doit organiser ses propres instructions.

Ce que l’usage de Project Pezzos suggère

La création des skills article/lab donne une première réponse pratique, mais pas encore une preuve de performance.

Mon intuition pour l’instant :

  • AGENTS.md doit contenir les contraintes locales et les garde-fous du projet.
  • Une skill doit contenir un workflow réutilisable, par exemple recherche d’article, plan de lab, exécution de lab, rédaction, gate contenu ou release.
  • Le harness doit contenir ce qui lance, isole, valide et collecte les preuves.
  • Un script de validation court vaut mieux qu’une longue instruction que personne ne vérifie.

Ce découpage a une qualité évidente : il évite de modifier les règles globales à chaque article. Une règle éditoriale durable peut vivre dans la doc canonique, la skill peut la rendre opérable, et le repo garde seulement ce qui dépend vraiment de Project Pezzos.

Mais ça ne suffit pas pour conclure. Une organisation propre peut seulement déplacer le bruit ailleurs.

Le test qui manque

Le bon test reste celui décrit dans la note Stax : produire un rapport de quick wins SEO sur les mêmes exports GA/GSC, avec plusieurs variantes comparables, puis regarder les rapports, les traces et les diffs avant de révéler la variante.

Cet article ne doit pas recopier tout le protocole. La question ici est plus précise : est-ce que le découpage AGENTS.md, skill et harness rend le travail plus fiable, plus lisible, ou plus facile à reprendre ?

Ce que je veux mesurer :

  • qualité du rapport produit ;
  • nombre de relances ou clarifications ;
  • traces disponibles pour comprendre le run ;
  • respect des données réellement fournies ;
  • taille et lisibilité du diff final ;
  • facilité à expliquer pourquoi une variante est meilleure.

Tant que ces résultats n’existent pas, je peux décrire la frontière visée, mais pas affirmer qu’elle améliore Project Pezzos.

Ce que je ne peux pas encore affirmer

  • qu’une skill améliore vraiment le résultat par rapport à un AGENTS.md court ;
  • qu’un harness plus riche produit de meilleurs diffs ;
  • qu’une règle déplacée dans une surface réutilisable reste plus facile à maintenir ;
  • que le découpage réduit les reprises ou les clarifications.

Conclusion provisoire

Les sources confirment que Codex dispose de plusieurs surfaces d’instruction et que les workflows agents modernes s’appuient sur du contexte, de l’isolation et des preuves. Elles ne prouvent pas encore le bon découpage pour Project Pezzos.

Ce que je garde pour l’instant : ne pas confondre rangement propre et meilleur résultat. Le découpage AGENTS.md, skill et harness doit maintenant être jugé sur un lab réel, avec un même data pack, des rapports comparables, des traces lisibles et un diff borné. Tant que ces résultats n’existent pas, ce n’est qu’une architecture d’instructions qui a l’air élégante.

Sources et liens utiles