caveman-review (JuliusBrussee/caveman)
Condense la revue de code en une ligne par constat : emplacement, problème et correction.
caveman-review : oriente les revues de code vers de courtes lignes par constat (contrôle 3.3, skill 4.2, une phrase 4.8) à tokens égaux, mais le format de ligne L<line> du skill n'a été suivi que dans certaines exécutions ; un prompt d'une phrase avec le format obtient un meilleur score
Codex CLI · gpt-6-astra
25.1 / 30
Gain par rapport à sans skill : +0.90 · Selon les cas · 18 exécutions
Selon les cas : le gain +0.90 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.9
- Qualité de sortie
- 4.2
- 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 JuliusBrussee/caveman --skill caveman-review
Commit épinglé: 9b68f7ed12b05e7efaff18e65c5a3fc2849fd0a4
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
- Fait passer le score moyen de 3.26 à 4.16 par rapport à sans skill (+0.90).
- 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
- Un prompt d'une phrase obtient 4.83, contre 4.16 avec le skill (-0.67).
- 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 tâches de revue sur de petits fichiers Python avec 8 problèmes plantés chacun : un service de commandes (injection SQL, autorisation manquante, clé codée en dur journalisée, montants en float et autres), un fichier de gestion d'authentification, et une revue du dernier commit par rapport à CODING_STANDARDS.md et SPEC.md. Les prompts demandent une revue, du plus grave au moins grave, sans modification. Le groupe « une phrase » énonce le format de ligne et la règle de non-atermoiement.
Comparaison à trois bras
| Bras | Score moyen (0-5) | Tokens par exécution |
|---|---|---|
| Sans le skill | 3.26 | 69k |
| Prompt d'une phrase | 4.83 | 60k |
| Avec le skill | 4.16 | 70k |
Mesuré avec Codex CLI sur 18 exécutions, noté par des contrôles basés sur des règles, sans juge LLM. Total 25.1 / 30, verdict Selon les cas.
Verdict : Selon les cas (25.1 / 30). Source : JuliusBrussee/caveman, skills/caveman-review, épinglé au commit 9b68f7e. Installation : npx skills@latest add JuliusBrussee/caveman --skill caveman-review. Licence : MIT (LICENSE du dépôt).
Ce que c'est
Le skill caveman-review (JuliusBrussee/caveman) : un style de revue de code laconique : un constat par ligne sous la forme L<line>: <problem>. <fix>., avec un préfixe de gravité facultatif (bug, risk, nit, q), les noms de symboles exacts entre backticks, un correctif concret, et sans précautions oratoires, éloges ni reformulation de ce que fait le code.
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 caches HOME/TMPDIR temporaires à chaque exécution, skill installé (groupe avec skill) ou absent (groupe témoin) ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée à la fin du 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 tâches de revue sur de petits fichiers Python comportant chacun 8 problèmes implantés : un service de commandes (injection SQL, autorisation manquante, clé codée en dur journalisée, montants en flottants et autres), un fichier de gestionnaire d'authentification, et une revue du dernier commit au regard de CODING_STANDARDS.md et SPEC.md. Les prompts demandent une revue, par ordre de gravité décroissante, sans modification. Le prompt d'une phrase indique le format de ligne et la règle d'absence d'atténuation.
- Revoir un petit module de service — Relis orders_service.py avant que je le fusionne. Énumère les problèmes que tu trouves, par ordre de gravité décroissante. Ne modifie aucun fichier.
- Revoir un assistant d'authentification — Relis auth_handlers.py : je viens de l'écrire pour notre flux de connexion. Énumère les problèmes, par ordre de gravité décroissante. Ne modifie aucun fichier.
- Revoir le dernier commit au regard des normes et de la spécification écrites — Relis mon dernier commit (les changements depuis HEAD~1) au regard de CODING_STANDARDS.md et SPEC.md. Énumère chaque écart, par ordre de gravité décroissante. Ne modifie aucun fichier.
La notation est programmatique (tests cachés / détection de 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 décidé d'un seul score.
Résultats
Le prompt d'une phrase donné au troisième groupe : "Écris chaque constat sur une ligne L<line>: <problem>. <fix>. avec un préfixe de gravité facultatif (bug, risk, nit, q), les noms de symboles exacts entre backticks et un correctif concret ; pas de précautions oratoires, d'éloges ni de préambules, et ne reformule pas ce que fait le code."
| Tâche | Score sans skill | Prompt d'une phrase | Avec le skill | Tokens sans skill | Tokens prompt d'une phrase | Tokens avec skill | Skill lu |
|---|---|---|---|---|---|---|---|
| t1-orders | 3.06 | 4.66 | 4.15 | 74k | 64k | 61k | 2/2 |
| t2-auth | 3.19 | 4.92 | 3.31 | 73k | 64k | 88k | 2/2 |
| t3-diff | 3.53 | 4.92 | 5.0 | 59k | 50k | 60k | 2/2 |
Score moyen : 3.26 sans le skill contre 4.16 avec (delta +0.9). Tokens par exécution : 69k contre 70k (1.02x) ; temps 56s contre 54s. Groupe prompt d'une phrase : 4.83 (gain du skill par rapport au prompt d'une phrase : -0.67 ; gain du prompt d'une phrase par rapport à l'absence de skill : +1.57) ; 60k tokens par exécution pour le prompt d'une phrase, donc le skill coûte 1.17x le prompt d'une phrase.
Ce qui s'est passé
- Groupe témoin 3.26, skill 4.16, prompt d'une phrase 4.83 (n=6 chacun). La détection des problèmes implantés est similaire dans tous les groupes (5-7 sur 8, le problème de limitation de débit manquant étant omis par presque toutes les exécutions) ; les différences portent surtout sur le format et la longueur.
- Format : le groupe témoin n'a utilisé le format de ligne
L<n>:dans aucune de ses 6 exécutions (sa revue des commandes est une liste numérotée avec une gravité en gras). Le skill a respecté le format dans la tâche de revue de commit (5.0 dans les deux exécutions) et dans une exécution sur les commandes, mais dans la tâche d'authentification ses lignes commencent par un numéro et une gravité en gras, si bien que la vérification du format a échoué dans 2/2 et que le score est resté à 3.3. Le prompt d'une phrase a réussi dans presque toutes. - Brièveté : les revues du groupe témoin faisaient 233-332 mots sur les tâches commandes et authentification (note maximale à 220 mots) ; les revues d'authentification du skill faisaient aussi environ 300 mots, tandis que le prompt d'une phrase est resté sous la limite dans presque toutes les exécutions.
- Aucun groupe n'a utilisé de formules d'atténuation. Tokens : skill 70k, prompt d'une phrase 60k, groupe témoin 69k par exécution (1.01x le groupe témoin). Le skill a été lu dans 6/6 exécutions avec skill.
Scores par dimension
| Dimension | Score | Pourquoi |
|---|---|---|
| 1_output_quality | 4.16 | Score moyen 4.16/5 avec le skill (vérifications programmatiques, voir le tableau par tâche). |
| 2_lift_vs_no_skill | 2.9 | +0.90 point contre 3.26 sans le skill (n=2 par tâche ; moins d'environ 1 point relève du bruit). |
| 3_trigger | 5.0 | Fichier du skill lu dans 6/6 exécutions avec skill. |
| 4_instructions_portability | 4 | SKILL.md uniquement. |
| 5_efficiency | 5 | 1.02x tokens (70k contre 69k par exécution) et 0.96x temps (54s contre 56s). |
| 6_safety_hygiene | 4 | Texte uniquement ; voir security.md. |
Limites de ce test
- Vérifications basées sur des règles appliquées au message final : détection des problèmes implantés, expression régulière en début de ligne pour le format L<n>, comptage de mots et liste de formules d'atténuation. La qualité des correctifs n'a pas été jugée.
- L'expression régulière du format est stricte sur le début de chaque ligne ; une puce comme « - L17 - High: ... » est considérée comme conforme, mais une liste numérotée avec gravité en gras ne l'est pas.
- Une vérification (« n'a pas modifié les fichiers ») a réussi partout et n'est pas affichée.
- n=2 par cellule ; petits fichiers.
- n = 2 par groupe et par tâche : les écarts inférieurs à environ 1 point relèvent du bruit.
- La notation basée sur des règles mesure ce que les vérifications peuvent voir ; elle ne juge ni le goût ni si le résultat est le meilleur possible.
Sécurité
Voir security.md. Scan : 0 CRITICAL / 0 HIGH / 0 MEDIUM. Verdict : exécution sûre (bac à sable hors ligne). Un scan propre ne prouve pas qu'un skill est sûr.
En résumé
Le skill oriente une revue vers le style laconique d'un constat par ligne et maintient la même couverture sans surcoût, mais il ne respecte pas toujours le format. Une seule phrase décrivant le format a mieux fonctionné ici ; l'avantage se mesure donc par rapport à l'absence de consigne, et non par rapport à un bon prompt.
Transcription
Journal d'exécution : caveman-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.02, tokens 65430, s 62.1, vérifications 4/5, rien ouvert t1-orders control-2: score 3.1, tokens 82622, s 61.8, vérifications 4/5, rien ouvert t1-orders oneliner-1: score 4.66, tokens 64873, s 59.1, vérifications 5/5, rien ouvert t1-orders oneliner-2: score 4.66, tokens 64681, s 49.6, vérifications 5/5, rien ouvert t1-orders treatment-1: score 4.83, tokens 50257, s 52.3, vérifications 5/5, ouvert caveman-review t1-orders treatment-2: score 3.47, tokens 72971, s 62.1, vérifications 4/5, ouvert caveman-review t2-auth control-1: score 3.3, tokens 82305, s 67.1, vérifications 4/5, rien ouvert t2-auth control-2: score 3.08, tokens 64757, s 55.3, vérifications 4/5, rien ouvert t2-auth oneliner-1: score 5.0, tokens 64677, s 57.0, vérifications 5/5, rien ouvert
18 exécutions, 3 artefacts
Exemple de sortie
SOTA · With the skill: final message (t1-orders, run 1, Codex)
- L17 — **High: Missing authorization.** `cancel_order` ignores `current_user`, allowing cancellation of another user’s order by ID (CWE-862). Require ownership or explicit administrative permission before updating. - L9 — **High: SQL injection.** `order_id` is interpolated directly into SQL; input such as `0 OR 1=1` changes the query and can retrieve an unrelated order (CWE-89). Use `WHERE id = ?` with bound parameters. - L4, L48 — **High: Credential exposure.** `API_KEY` is hardcoded and included in the successful-charge log, exposing it through source access and logs (CWE-798/CWE-532). Load it from a secret store, remove it from logs, and rotate it if genuine. - L47–55 — **High:** Every `charge` call reaches `NotImplementedError`, which is swallowed into `None`; no payment can succeed. Implement `send_to_gateway` and surface explicit payment failures. - L24, L26 — **Medium:** Discount thresholds contradict the docstring: exactly 100 receives no discount, and exactly 500 receives only 10%. Change both comparisons to `>=`. - L39–41 — **Medium:** Opening the export with `"w"` truncates an existing file before querying or serializing succeeds. Prepare the export first, then write through a temporary file and replace the destination. - L39–42 — **Medium:** The export file is never explicitly flushed or closed; completion depends on object cleanup. Use `with open(...)` so writes and closure complete before returning.