codebase-design (mattpocock/skills)

Avis

Codex CLI 0.166 (gpt-6-astra, low reasoning) sur un PC Windows de test dédié, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (traitement) ou absent (contrôle) ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt d'une phrase »), 2 exécutions par groupe et par tâche, réseau coupé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée ci-dessous). Un petit backend de boutique avec six points de friction plantés (validateurs et wrappers monétaires superficiels, un service d'inventaire passe-plat, un adaptateur de paiement unique, de la logique dupliquée, et autres). Tâches : écrire un rapport HTML des améliorations d'architecture, un rapport limité au paiement et à l'inventaire, et « pourquoi place_order est-il difficile à tester et comment le corriger » (réponse dans le chat). Les prompts ne nomment aucun terme de design. Le groupe « une phrase » énonce l'idée de profondeur et les points à signaler.

Comparaison à trois bras

Mesuré avec Codex CLI sur 18 exécutions, noté par des contrôles basés sur des règles, sans juge LLM. Total 23.6 / 30, verdict Selon les cas.

Verdict : Selon le cas (23.6 / 30). Source : mattpocock/skills, skills/engineering/codebase-design, épinglé au commit 4ae2317. Installation : npx skills@latest add mattpocock/skills --skill codebase-design. Licence : MIT (LICENSE du dépôt).

Présentation

Le skill codebase-design (mattpocock/skills) : une manière de relire l’architecture par la profondeur des modules : des modules profonds dont une petite interface masque beaucoup de comportement ; signaler les modules superficiels qui ne font que transmettre, les coutures à adaptateur unique qui restent hypothétiques, la logique dupliquée et le comportement testé uniquement via des helpers ; indiquer où placer une couture pour que le comportement soit testé à travers l’interface.

Méthode de test

Codex CLI 0.166 (gpt-6-astra, raisonnement faible) sur une machine de test Windows dédiée, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (groupe avec skill), absent (groupe témoin), ou absent avec l’exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt en une phrase »), 2 exécutions par groupe et par tâche, réseau désactivé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée plus bas).

Un petit backend de boutique avec six points de friction implantés (validateurs et wrappers monétaires superficiels, un service d’inventaire qui ne fait que transmettre, un adaptateur de paiement unique, de la logique dupliquée, entre autres). Tâches : rédiger un rapport HTML d’améliorations d’architecture, un rapport limité au paiement et à l’inventaire, et « pourquoi place_order est-il difficile à tester et comment le corriger ? » (réponse dans le chat). Les prompts ne nomment aucun terme de design. Le prompt en une phrase énonce l’idée de profondeur et les points à signaler.

1. Analyse d’architecture sur tout le dépôt — Passez en revue ce petit backend de boutique pour des améliorations d’architecture : où une restructuration rendrait-elle le code plus facile à modifier et à tester ? Rédigez vos conclusions dans un rapport HTML autonome nommé report.html dans ce dossier (n’ouvrez pas de navigateur et ne démarrez pas de se…
2. Paiement et inventaire uniquement — Regardez uniquement les parties paiement et inventaire de ce backend et dites-moi quelles restructurations seraient rentables. Rédigez vos conclusions dans un rapport HTML autonome nommé report.html dans ce dossier (n’ouvrez pas de navigateur et ne démarrez pas de serveur) et ne modifiez aucun co…
3. Pourquoi place_order est-il difficile à tester ? — Il semble pénible d’écrire un vrai test pour place_order dans ce backend. Pourquoi, et quelle restructuration corrigerait cela ? Ne modifiez aucun fichier ; répondez dans votre message final.

Le scoring est programmatique (tests cachés / détection des problèmes implantés / vérifications de contraintes / rendu + OCR le cas échéant), de 0 à 5 par exécution. Aucun juge LLM n’a attribué de score.

Résultats

Le prompt en une phrase donné au troisième groupe : « Juge les modules par leur profondeur : un module profond a une petite interface qui masque beaucoup de comportement ; signale les modules superficiels qui ne font que transmettre, les coutures hypothétiques à adaptateur unique, la logique dupliquée et le comportement testé uniquement via des helpers, et indique où placer une couture pour que le comportement soit testé à travers l’interface. »

Score moyen : 3.21 sans le skill contre 3.92 avec (écart +0.71). Tokens par exécution : 119k contre 133k (1.12x) ; temps 154s contre 158s. Groupe « prompt en une phrase » : 4.54 (gain du skill sur ce prompt : -0.63 ; gain du prompt par rapport à l’absence de skill : +1.34) ; tokens du prompt : 114k par exécution, donc le skill coûte 1.17x le prompt en une phrase.

Ce qui s’est passé

• Témoin 3.21, skill 3.92, prompt en une phrase 4.54 (n=6 chacun). Sans consigne, les rapports HTML n’utilisaient presque aucun vocabulaire d’architecture (0-2 occurrences de deep/shallow/seam/interface, là où la vérification en attend 6) dans 4 exécutions sur 4. Les rapports du skill l’utilisaient dans les 4 exécutions, tout comme le prompt en une phrase.
• Analyse de tout le backend : skill 4.24 et 3.41, prompt 3.41 et 3.86, témoin 2.88 et 2.2. Les deux bras guidés ont trouvé 3-4 des 6 points implantés ; les wrappers de validateurs superficiels et l’adaptateur de paiement unique ont été manqués dans plusieurs exécutions par tous les bras.
• Tâche ciblée paiement et inventaire : skill 3.75 dans les deux exécutions, témoin 2.5 dans les deux, prompt 5.0 dans les deux. Toutes les exécutions du skill et du témoin n’ont trouvé qu’un des deux points (l’adaptateur de paiement unique hypothétique a été manqué) ; le prompt en une phrase a trouvé les deux.
• Pourquoi place_order est difficile à tester : tous les bras sont proches (témoin 4.17 et 5.0, skill 4.17 et 4.17, prompt 5.0 et 5.0) ; les exécutions du skill ont manqué une cause (tests via helpers uniquement) dans une exécution et les couches de simple transmission dans une autre.
• Tokens : skill 133k, prompt 114k, témoin 119k par exécution (1.12x le témoin). Le skill a été lu dans 6/6 exécutions avec skill.

Scores par dimension

Limites de ce test

• Vérifications de détection par règles sur le texte des rapports (mots-clés près des noms de fichiers) et comptage du vocabulaire ; la pertinence des restructurations proposées n’a pas été jugée et les rapports n’ont pas été ouverts dans un navigateur.
• La vérification du vocabulaire récompense les termes propres au skill, que le prompt en une phrase nomme aussi, et favorise les bras guidés.
• La vérification « avant/après » ne ressort que pour 2 exécutions en échec sur la tâche d’analyse ; ce n’est pas un facteur discriminant.
• n=2 par cellule ; un seul petit dépôt.
• n = 2 par groupe et par tâche : un écart inférieur à ~1 point relève du bruit.
• Le scoring par règles mesure ce que les vérifications peuvent voir ; il ne peut juger du goût ni du caractère optimal d’un résultat.

Sécurité

Voir security.md. Scan : 0 CRITICAL / 0 HIGH / 0 MEDIUM. Verdict : exécution sans danger (sandbox sans réseau). Un scan propre ne prouve pas qu’un skill est sûr.

En résumé

Le skill donne clairement à la revue le cadre de la profondeur des modules qui manque à un prompt nu, avec un léger gain de score sur le témoin, mais la même idée en une phrase trouve davantage de problèmes implantés pour moins de tokens : le gain est donc surtout stylistique.