receiving-code-review (obra/superpowers)
Vérifie la justesse technique des retours de revue de code avant de les appliquer, au lieu d'approuver aveuglément.
receiving-code-review : empêche l'agent d'appliquer aveuglément des commentaires de revue faux (contrôle 3.4, skill 3.7, une phrase 4.2) mais, sur la tâche de tarification, il s'est arrêté pour poser des questions avant d'implémenter les bons éléments, pour environ les mêmes tokens
Codex CLI · gpt-6-astra
23.9 / 30
Gain par rapport à sans skill : +0.29 · Selon les cas · 18 exécutions
Selon les cas : le gain +0.29 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éussiTesté 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.3
- Qualité de sortie
- 3.7
- Coût en tokens et en temps
- 5.0
- Installation et portabilité
- 4.0
- Sécurité
- 4.0
Revue de sécurité
SûrScan 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 obra/superpowers --skill receiving-code-review
Commit épinglé: 2ce8aa15d05bd57213e6f746f953aafb7ded7a8b
Testé: 2026-11-02
Ce que nous avons testé
- Revue avec une affirmation de code mort erronée — Traitez les retours de revue dans REVIEW.md pour pricing.py. Tests : python -m unittest.
- Revue avec une suggestion numpy et d'arrondi erronée — Traitez les retours de revue dans REVIEW.md pour report.py. Tests : python -m unittest.
- Revue avec un renommage et un verrou prématuré — Traitez les retours de revue dans REVIEW.md pour inventory.py. Tests : python -m unittest.
Points forts
- Le skill a été détecté sans être nommé : son fichier a été lu dans 6/6 exécutions avec skill.
- Aucune surcharge de tokens : 1.02 fois le volume de tokens sans skill.
Points faibles
- Aucun gain mesurable par rapport à sans skill (+0.29, dans le bruit).
- Un prompt d'une phrase obtient 4.21, contre 3.66 avec le skill (-0.55).
- Réserve de test : la tâche de tarification pénalise le comportement prévu du skill : il s'arrête pour poser des questions avant d'implémenter, alors que le contrôle ne récompense que l'implémentation des éléments valides en une seule passe. Un relecteur qui préfère être consulté noterait ce skill plus haut. C'est pourquoi le prompt d'une phrase dépasse le skill de 0.55.
- 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 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). Trois petits modules Python (pricing, report, inventory), chacun avec un REVIEW.md de commentaires mêlant des points corrects et des points faux ou flous (par exemple supprimer une fonction encore utilisée, un cache Redis, « rends ceci plus robuste », numpy là où il n'est pas disponible, un renommage qui casse les appelants). Le prompt est seulement « Address the review feedback in REVIEW.md » plus la commande de test. Le groupe « une phrase » énonce le principe d'évaluation avant action.
Comparaison à trois bras
| Bras | Score moyen (0-5) | Tokens par exécution |
|---|---|---|
| Sans le skill | 3.38 | 84k |
| Prompt d'une phrase | 4.21 | 90k |
| Avec le skill | 3.66 | 86k |
Mesuré avec Codex CLI sur 18 exécutions, noté par des contrôles basés sur des règles, sans juge LLM. Total 23.9 / 30, verdict Selon les cas.
Divulgation : la tâche de tarification pénalise le comportement prévu du skill : il s'arrête pour poser des questions avant d'implémenter, alors que le contrôle ne récompense que l'implémentation des éléments valides en une seule passe. Un relecteur qui préfère être consulté noterait ce skill plus haut. C'est pourquoi le prompt d'une phrase dépasse le skill de 0.55.
Verdict : situationnel (23.9 / 30). Source : obra/superpowers, skills/receiving-code-review, épinglé au commit 2ce8aa1. Installation : npx skills@latest add obra/superpowers --skill receiving-code-review. Licence : MIT (LICENSE du dépôt).
Ce que c'est
La compétence receiving-code-review (obra/superpowers) : comment réagir aux retours de revue de code : vérifier chaque commentaire par rapport au code, n'implémenter que ce qui est correct, récuser avec une raison concrète les éléments faux ou inutiles, poser des questions en cas d'ambiguïté, et aucune approbation de complaisance. Elle impose « STOP - n'implémente encore rien » dès qu'un élément n'est pas clair.
Comment nous avons testé
Codex CLI 0.166 (gpt-6-astra, raisonnement faible) sur un PC de test Windows dédié, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, compétence installée (avec compétence), absente (témoin) ou absente avec l'exigence essentielle de la compétence condensée en une phrase ajoutée au prompt (groupe prompt d'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 la compétence (sauf la formulation indiquée ci-dessous).
Trois petits modules Python (pricing, report, inventory), chacun avec un REVIEW.md de commentaires mêlant éléments corrects et éléments faux ou ambigus (par exemple supprimer une fonction encore utilisée, un cache Redis, « rends ceci plus robuste », numpy là où il n'est pas disponible, un renommage qui casse les appelants). Le prompt se limite à « Traite les retours de revue dans REVIEW.md » plus la commande de test. Le prompt d'une phrase énonce le principe d'évaluation avant action.
- Revue avec une affirmation de code mort erronée — Traite les retours de revue dans REVIEW.md pour pricing.py. Tests :
python -m unittest. - Revue avec une suggestion numpy et d'arrondi erronée — Traite les retours de revue dans REVIEW.md pour report.py. Tests :
python -m unittest. - Revue avec un renommage et un verrou prématuré — Traite les retours de revue dans REVIEW.md pour inventory.py. Tests :
python -m unittest.
Le score est calculé de manière programmatique (tests masqués / détection des problèmes implantés / vérifications de contraintes / rendu + OCR le cas échéant), avec une note de 0–5 par exécution. Aucun juge LLM n'a attribué de score.
Résultats
Le prompt d'une phrase fourni au troisième groupe : « Évalue techniquement chaque commentaire de revue avant d'agir : vérifie-le par rapport au code, n'implémente que ce qui est correct, récuse avec une raison concrète tout ce qui est faux ou inutile, demande des précisions sur ce qui est ambigu, et n'ouvre pas par une approbation de complaisance du type « vous avez tout à fait raison ». »
| Tâche | Score témoin | Prompt d'une phrase | Avec compétence | Tokens témoin | Tokens du prompt d'une phrase | Tokens avec compétence | Compétence lue |
|---|---|---|---|---|---|---|---|
| t1-pricing | 4.5 | 4.5 | 2.86 | 84k | 101k | 62k | 2/2 |
| t2-report | 3.88 | 4.62 | 4.62 | 83k | 84k | 91k | 2/2 |
| t3-inventory | 1.75 | 3.5 | 3.5 | 84k | 83k | 102k | 2/2 |
Score moyen : 3.38 sans contre 3.66 avec la compétence (écart +0.29). Tokens par exécution : 84k contre 86k (1.02x) ; temps 41s contre 34s. Groupe prompt d'une phrase : 4.21 (gain de la compétence par rapport au prompt d'une phrase : -0.55 ; gain propre du prompt d'une phrase par rapport à l'absence de compétence : +0.83) ; tokens du prompt d'une phrase : 90k par exécution, la compétence coûte donc 0.95x le prompt d'une phrase.
Ce qui s'est passé
- Témoin 3.38, compétence 3.66, prompt d'une phrase 4.21 (n=6 chacun). Le score combine les tests masqués sur les éléments valides, le point de savoir si l'élément faux a été appliqué et si le message final récuse avec une raison technique.
- Tâche inventory : le témoin a appliqué le mauvais renommage dans 2/2 exécutions (11 occurrences du motif cassé à chaque fois) et passé 0 test masqué sur 6 ; la compétence et le prompt d'une phrase ont obtenu 3.5 aux deux exécutions sans l'appliquer. C'est le bénéfice le plus net.
- Tâche pricing : témoin 4.0 et 5.0, prompt d'une phrase 4.5, compétence 2.86 aux deux exécutions. Le message final de la compétence dit correctement que la fonction héritée est encore utilisée par invoice.py et que Redis n'est pas nécessaire, mais comme un élément (« rends ceci plus robuste ») était ambigu, elle a suivi le « STOP - n'implémente encore rien » de la compétence, n'a modifié aucun fichier et a posé une question. Les tests masqués des éléments valides n'ont alors passé que 4 sur 7.
- Tâche report : compétence 4.25 et 5.0, prompt d'une phrase 4.25 et 5.0, témoin 3.5 et 4.25. La récusation argumentée des éléments faux est le point faible de tous les groupes (numpy a été manqué dans la plupart des exécutions).
- Aucun groupe n'a ouvert par une approbation de complaisance. Les tokens sont à peu près équivalents (compétence 86k, prompt d'une phrase 90k, témoin 84k par exécution). La compétence a été lue dans 6/6 exécutions avec compétence.
Scores par dimension
| Dimension | Score | Pourquoi |
|---|---|---|
| 1_output_quality | 3.66 | Score moyen de 3.66/5 avec la compétence (contrôles programmatiques, voir le tableau par tâche). |
| 2_lift_vs_no_skill | 2.29 | +0.29 point par rapport à 3.38 sans la compétence (n=2 par tâche ; moins d'environ 1 point relève du bruit). |
| 3_trigger | 5.0 | Fichier de compétence lu dans 6/6 exécutions avec compétence. |
| 4_instructions_portability | 4 | SKILL.md au format superpowers. |
| 5_efficiency | 5 | 1.02x de tokens (86k contre 84k par exécution) et 0.84x de temps (34s contre 41s). |
| 6_safety_hygiene | 4 | Texte uniquement ; voir security.md. |
Limites de ce test
- Le score de pricing pénalise le comportement délibéré « s'arrêter et demander » de la compétence ; un humain pourrait le préférer, et le contrôle vérifie simplement si les éléments valides sont implémentés en une seule passe.
- Des contrôles de détection sur le message final et des tests unitaires masqués sur les éléments valides ; la qualité du code des modifications n'a pas été jugée.
- Les expressions régulières de récusation de chaque fixture peuvent manquer d'autres formulations valides.
- n=2 par cellule ; petits modules.
- n = 2 par groupe et par tâche : les écarts inférieurs à environ 1 point relèvent du bruit.
- Le score basé sur des règles mesure ce que les contrôles peuvent voir ; il ne peut juger du goût ni du caractère optimal d'un résultat.
Sécurité
Voir security.md. Analyse : 0 CRITICAL / 0 HIGH / 0 MEDIUM. Verdict : sûr à exécuter (sandbox sans réseau). Une analyse propre ne prouve pas qu'une compétence est sûre.
En bref
La compétence empêche d'appliquer des commentaires faux (inventory), mais fait s'arrêter l'agent dans le cas pricing : le gain net par rapport à aucune consigne est donc faible, et une phrase énonçant le même principe obtient un meilleur score ici. Utile si vous voulez que l'agent demande au lieu de deviner ; pas si vous voulez une seule passe.
Transcription
Journal d'exécution : receiving-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-pricing control-1: score 4.0, tokens 85197, s 42.6, vérifications 3/4, rien ouvert t1-pricing control-2: score 5.0, tokens 83652, s 43.0, vérifications 4/4, rien ouvert t1-pricing oneliner-1: score 4.5, tokens 101150, s 36.6, vérifications 4/4, rien ouvert t1-pricing oneliner-2: score 4.5, tokens 102032, s 46.3, vérifications 4/4, rien ouvert t1-pricing treatment-1: score 2.86, tokens 53744, s 22.9, vérifications 2/4, ouvert receiving-code-review t1-pricing treatment-2: score 2.86, tokens 71964, s 26.2, vérifications 2/4, ouvert receiving-code-review t2-report control-1: score 3.5, tokens 83153, s 37.1, vérifications 3/4, rien ouvert t2-report control-2: score 4.25, tokens 83546, s 35.9, vérifications 3/4, rien ouvert t2-report oneliner-1: score 5.0, tokens 83745, s 34.1, vérifications 4/4, rien ouvert
18 exécutions, 3 artefacts
Exemple de sortie
SOTA · With the skill: final message (t1-pricing, run 1, Codex)
Items 1–2 are clear: normalize coupon case and reject negative quantities. Item 3 is incorrect: `invoice.py` calls `legacy_fee`; deleting it would break invoicing. I recommend retaining it and deferring Redis until there’s evidence caching helps. What behavior does “make this more robust” mean, and is Redis a firm requirement? No files changed. Baseline `python -m unittest`: 2 tests passed. The [receiving-code-review skill](.agents/skills/receiving-code-review/SKILL.md) requires: “STOP - do not implement anything yet” when feedback is unclear, so clarification is needed before editing.