code-review (Matt Pocock)

Name: code-review (Matt Pocock) review
Item: code-review (Matt Pocock)
Rating: 23.5
Author: Agent Skills

Examine les changements depuis un commit ou une branche, côté normes du dépôt et côté spécification d'origine.

La revue de code de Matt Pocock : même rappel que Codex seul sur 3 tâches de revue, 1.5 fois les tokens

Selon les casSûr

Codex CLI · gpt-6-astra

23.5 / 30

Gain par rapport à sans skill : +0.08 · Selon les cas · 18 exécutions

Selon les cas : le gain +0.08 est inférieur à +1.0. Pour être recommandé, il faut un total de 22/30, une qualité de sortie de 3.5 et un gain de +1.0.

SOTA

Réussi

Testé avec Codex.

Couvre Codex, Claude Code

Codex CLI 0.166 (palier SOTA) : 18 exécutions notées. Une réussite ici couvre aussi Claude Code selon notre règle de palier ; elle ne dit rien du second palier.

Scores

Chaque dimension va de 0 à 5 et les six forment le total sur 30. 5 est la meilleure note dans chaque dimension. Coût 5 signifie bon marché et rapide. Installation 5 signifie facile.

Fiabilité du déclenchement: 5.0
Gain par rapport à sans skill: 2.1
Qualité de sortie: 4.5
Coût en tokens et en temps: 3.0
Installation et portabilité: 4.0
Sécurité: 5.0

Revue de sécurité

Sûr

Scan statique : 0 CRITIQUE / 0 ÉLEVÉ / 0 MOYEN. Revue manuelle : sûr à exécuter dans un bac à sable sans réseau (aucun problème détecté). Un scan propre ne prouve pas qu'un skill est sûr.

Installer

npx skills@latest add mattpocock/skills --skill code-review

Source

Commit épinglé: 4ae2317ddb22b046e26455e4f9c9b3aaaf62212d

Testé: 2026-11-02

Ce que nous avons testé

Revoir un petit module de service — Relisez orders_service.py avant que je fusionne. Listez les problèmes trouvés, du plus grave au moins grave. Ne modifiez aucun fichier.
Revoir un helper d'authentification — Relisez auth_handlers.py : je viens de l'écrire pour notre flux de connexion. Listez les problèmes, du plus grave au moins grave. Ne modifiez aucun fichier.
Revoir le dernier commit par rapport aux normes écrites et à la spec — Relisez mon dernier commit (les changements depuis HEAD~1) par rapport à CODING_STANDARDS.md et SPEC.md. Listez chaque écart, du plus grave au moins grave. Ne modifiez aucun fichier.

Points forts

Le skill a été détecté sans être nommé : son fichier a été lu dans 6/6 exécutions avec skill.

Points faibles

Aucun gain mesurable par rapport à sans skill (+0.08, dans le bruit).
n=2 par tâche et par bras ; les écarts inférieurs à environ 1 point sont du bruit.

Avis

Codex CLI 0.166 (gpt-6-astra, low reasoning) sur un Mac de test, 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). Deux revues de fichier unique (un service de commandes avec 8 problèmes plantés, dont trois sans rapport avec la sécurité ; un helper d'authentification avec 8 problèmes plantés) et une revue du dernier commit par rapport à CODING_STANDARDS.md et SPEC.md (8 écarts plantés), qui est l'usage prévu du skill. Tous les prompts sont en lecture seule (« liste les problèmes, du plus grave au moins grave, ne modifie pas les fichiers »).

Comparaison à trois bras

Bras	Score moyen (0-5)	Tokens par exécution
Sans le skill	4.37	78k
Prompt d'une phrase	4.37	77k
Avec le skill	4.45	114k

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

Verdict : selon les cas (23.5 / 30). Source : mattpocock/skills, skills/engineering/code-review, épinglé au commit 4ae2317. Installation : npx skills@latest add mattpocock/skills --skill code-review. Licence : MIT (LICENSE du dépôt).

Présentation

Le skill code-review de mattpocock/skills (engineering/code-review). Il relit les changements depuis une référence donnée selon deux axes : le code respecte-t-il les normes de codage documentées du dépôt (et les code smells courants), et implémente-t-il ce que la spec demandait ; il est écrit pour des dépôts dotés de documents de normes et de spec, et pour un usage avec des sous-agents. Markdown uniquement, aucun script.

Notre méthode de test

Codex CLI 0.166 (gpt-6-astra, raisonnement faible) sur une machine de test Mac, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (groupe traité) ou absent (groupe témoin), ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « 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).

Deux revues d'un seul fichier (un service de commandes avec 8 anomalies introduites, dont trois sans rapport avec la sécurité ; un utilitaire d'authentification avec 8 anomalies introduites) et une revue du dernier commit au regard de CODING_STANDARDS.md et SPEC.md (8 écarts introduits), qui est l'usage prévu du skill. Tous les prompts sont en lecture seule (« listez les problèmes, les plus graves d'abord, ne modifiez aucun fichier »).

Relire un petit module de service — Relis orders_service.py avant que je le fusionne. Liste les problèmes que tu trouves, les plus graves d'abord. Ne modifie aucun fichier.
Relire un utilitaire d'authentification — Relis auth_handlers.py : je viens de l'écrire pour notre flux de connexion. Liste les problèmes, les plus graves d'abord. Ne modifie aucun fichier.
Relire le dernier commit au regard des normes écrites et de la spec — Relis mon dernier commit (les changements depuis HEAD~1) au regard de CODING_STANDARDS.md et SPEC.md. Liste chaque écart, le plus grave d'abord. Ne modifie aucun fichier.

Le scoring est programmatique (tests cachés / rappel des anomalies introduites / vérifications de contraintes / rendu + OCR le cas échéant), 0–5 par exécution. Aucun juge LLM n'a décidé d'un seul score.

Résultats

Le prompt d'une phrase donné au troisième groupe : « Relis selon deux axes : le code respecte-t-il les normes de codage documentées du dépôt (plus les code smells courants), et implémente-t-il ce que la spec demandait ; cite le fichier et la ligne pour chaque constat. »

Tâche	Score témoin	Une phrase	Avec le skill	Tokens témoins	Tokens (une phrase)	Tokens avec le skill	Skill lu
t1-orders	3.82	3.59	3.82	79k	79k	94k	2/2
t2-auth	4.29	4.53	4.53	76k	70k	93k	2/2
t3-diff	5.0	5.0	5.0	78k	80k	153k	2/2

Score moyen : 4.37 sans contre 4.45 avec le skill (delta +0.08). Tokens par exécution : 78k contre 114k (1.46x) ; temps 44s contre 57s. Groupe « une phrase » : 4.37 (gain du skill sur le prompt d'une phrase : +0.08 ; gain du prompt d'une phrase sur l'absence de skill : +0.0) ; 77k tokens par exécution pour le prompt d'une phrase, donc le skill coûte 1.49x ce prompt.

Ce qui s'est passé

Aucun gain mesurable : score moyen 4.37 sans le skill, 4.37 avec la version en une phrase, 4.45 avec le skill. Rappel des anomalies introduites par exécution : 5.0 sur 8 pour le témoin, 5.0 pour la phrase unique, 5.1 pour le skill.
Sur la tâche pour laquelle le skill a été écrit (relire un commit au regard d'un fichier de normes et d'une spec), chaque groupe a trouvé les 8 écarts dans 6 exécutions sur 6. Codex seul lit déjà CODING_STANDARDS.md et SPEC.md et compare le diff quand on le lui demande.
Sur les deux revues d'un seul fichier, chaque groupe a trouvé 5 à 7 des 8 anomalies introduites. Les oublis étaient les mêmes d'un groupe à l'autre (argent en float, un secret écrit dans les logs, aucune limitation de débit à la connexion), et rien de ce que le skill ajoute n'y a changé quoi que ce soit.
Le skill a été lu dans 6/6 exécutions et a coûté 114k tokens par exécution contre 78k (1.5x) ; sur la tâche de revue de commit, 154k contre 79k (environ 2x), le cas le plus lourd. Le prompt d'une phrase coûtait autant que le témoin. Aucune exécution n'a modifié de fichier.
Une réserve sur le scoring : les éléments sont détectés par regex, donc un constat formulé différemment peut compter comme un oubli.

Scores par dimension

Dimension	Score	Pourquoi
1_output_quality	4.45	Score moyen de 4.45/5 avec le skill (vérifications programmatiques, voir le tableau par tâche).
2_lift_vs_no_skill	2.08	+0.08 point contre 4.37 sans le skill (n=2 par tâche ; en dessous d'environ 1 point, c'est du bruit).
3_trigger	5.0	Fichier du skill lu dans 6/6 exécutions avec le skill.
4_instructions_portability	4	Écrit pour des dépôts dotés de documents de normes/spec et pour des agents capables de lancer des sous-agents ; fonctionne ailleurs comme de simples instructions.
5_efficiency	3	1.46x de tokens (114k contre 78k par exécution) et 1.30x de temps (57s contre 44s).
6_safety_hygiene	5	Markdown uniquement ; aucun script, aucune commande.

Limites de ce test

Le skill est conçu pour répartir les deux axes entre des sous-agents et pour lire les documents du dépôt ; une exécution Codex non interactive sur un petit dépôt ne montre pas si cela aide sur un gros diff.
Des anomalies introduites dans de tout petits fichiers ; la qualité des explications, l'ordre de gravité et les faux positifs n'ont pas été notés.
Le prompt d'une phrase reformule les deux axes du skill ; une équipe sans normes documentées n'aurait rien à donner au premier axe.
n = 2 par groupe et par tâche : les différences inférieures à environ 1 point relèvent du bruit.
Le scoring basé sur des 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 : sûr à exécuter (sandbox sans réseau). Un scan propre ne prouve pas qu'un skill est sûr.

En résumé

Quand on lui demande de relire un commit au regard de normes écrites et d'une spec, Codex seul trouvait déjà tous les écarts introduits, et le skill ajoutait des tokens (1.5x à 2x) sans en trouver davantage. Il peut néanmoins aider une équipe qui veut que chaque revue suive le même format à deux axes, ce que ce test ne mesure pas.

Transcription

Journal d'exécution : code-review (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.)
Colonnes : tâche, groupe-exécution, score (0-5), tokens, secondes, vérifications réussies, fichiers de la skill ouverts par l'agent.

t1-orders control-1: score 3.59, tokens 79037, s 43.8, vérifications 2/2, rien ouvert
t1-orders control-2: score 4.06, tokens 79487, s 50.4, vérifications 2/2, rien ouvert
t1-orders oneliner-1: score 3.59, tokens 97051, s 50.6, vérifications 2/2, rien ouvert
t1-orders oneliner-2: score 3.59, tokens 61642, s 42.5, vérifications 2/2, rien ouvert
t1-orders treatment-1: score 4.06, tokens 65668, s 44.1, vérifications 2/2, ouvert code-review
t1-orders treatment-2: score 3.59, tokens 123428, s 56.0, vérifications 2/2, ouvert code-review
t2-auth control-1: score 4.53, tokens 76436, s 43.2, vérifications 2/2, rien ouvert
t2-auth control-2: score 4.06, tokens 76339, s 43.5, vérifications 2/2, rien ouvert
t2-auth oneliner-1: score 4.53, tokens 61176, s 49.9, vérifications 2/2, rien ouvert

18 exécutions, 3 artefacts

Exemple de sortie

SOTA · With the skill: final message (t1-orders, run 1, Codex)

Found six problems, most serious first: 1. **High — Missing cancellation authorization** ([line 13](orders_service.py:13)). `current_user` is never checked. Anyone able to call this function can cancel another user’s order by supplying its ID. Verify ownership or administrative permission before updating. 2. **High — SQL injection** ([line 9](orders_service.py:9)). `order_id` is interpolated directly into SQL. A value such as `"0 OR 1=1"` changes the query and can return another order. Use a parameterized query. 3. **High — Credential exposure** ([line 4](orders_service.py:4), [line 48](orders_service.py:48)). A live-looking API key is hardcoded, and the successful charge path prints it to logs. Load credentials from secure configuration and remove the logging. If this key is real, rotate it. 4. **High — Charging always fails silently** ([lines 45–55](orders_service.py:45)). `send_to_gateway()` always raises `NotImplementedError`; `charge()` catches it and returns `None`. No payment can succeed, and callers receive no explicit failure. Implement the gateway and propagate or explicitly report failures. 5. **Medium — Discount thresholds are incorrect** ([line 24](orders_service.py:24)). The documented “or more” thresholds require `>=`. Currently, a total of 100 receives no discount, and 500 receives only 10%, yielding 100 and 450 instead of 90 and 400. 6. **Medium — Export file is never explicitly closed** ([line 39](orders_service.py:39)). Buffered output and resource cleanup depend on garbage collection, including on exceptions. Use a `with open(...)` block to ensure flushing and closing. Static review only; no files changed.

Voir Pro