caveman (JuliusBrussee/caveman, SKILL.md only)

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). Chaque prompt est une question technique (une boucle useEffect infinie, une requête Postgres lente, merge vs rebase sur une branche partagée) terminée par « Be brief; I'm paying per token. » Cette phrase est l'un des déclencheurs du skill, et le groupe de contrôle reçoit la même. Le test demande donc ce que le skill apporte de plus qu'une simple demande de brièveté.

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 21.7 / 30, verdict Selon les cas.

Verdict : selon les cas (21.7 / 30). Source : JuliusBrussee/caveman, skills/caveman, épinglé au commit 9b68f7e. Installation : npx skills@latest add JuliusBrussee/caveman --skill caveman. Licence : MIT (LICENSE du dépôt ; les hooks et l'installateur du dépôt n'ont PAS été installés ni exécutés).

Présentation

Le skill caveman (uniquement skills/caveman/SKILL.md ; les hooks et l'installateur du dépôt n'ont pas été installés). Un style de réponse laconique : répondre d'abord, supprimer les salutations et les récapitulatifs, des mots courts, des articles supprimés mais jamais les négations, conserver tels quels le code, les chemins, les nombres et les erreurs, une prose normale pour les avertissements et les actions irréversibles. Il se déclenche sur « caveman mode », « be brief », « less tokens ». Environ 600 mots de Markdown, 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).

Chaque prompt est une question technique (une boucle useEffect infinie, une requête Postgres lente, merge ou rebase sur une branche partagée) terminée par « Be brief; I'm paying per token. » Cette phrase est l'un des déclencheurs du skill, et le groupe témoin reçoit la même. Le test demande donc ce que le skill apporte en plus d'une simple demande de brièveté.

1. Expliquer une boucle useEffect infinie — Dans un composant React, j'ai const fetchData = async () => { const r = await fetch('/api/items'); setItems(await r.json()); } et useEffect(() => { fetchData(); }, [fetchData]);. Le composant refait la requête en boucle sans fin. Pourquoi, et quelle est la correction ? Be brie…
2. Corriger une requête Postgres lente — Postgres : SELECT id, total FROM orders WHERE customer_id = 42 ORDER BY created_at DESC LIMIT 20; met plusieurs secondes sur une table orders de 50M de lignes qui n'a qu'un index de clé primaire. Que dois-je faire ? Be brief; I'm paying per token.
3. Merge ou rebase sur une branche partagée — Mon équipe travaille sur une branche de fonctionnalité partagée que d'autres ont déjà récupérée. Je veux y intégrer le dernier main. Dois-je utiliser git merge ou git rebase, et pourquoi ? Be brief; I'm paying per token.

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 : « Réponds de façon laconique : réponds d'abord, sans salutation, remplissage, précaution oratoire ni récapitulatif, supprime les articles inutiles, garde chaque fait technique, code, nombre et négation exacts. »

Score moyen : 4.67 sans contre 4.67 avec le skill (delta +0.0). Tokens par exécution : 14k contre 31k (2.20x) ; temps 12s contre 19s. Groupe « une phrase » : 4.5 (gain du skill sur le prompt d'une phrase : +0.17 ; gain du prompt d'une phrase sur l'absence de skill : -0.17) ; 14k tokens par exécution pour le prompt d'une phrase, donc le skill coûte 2.20x ce prompt.

Ce qui s'est passé

• Sans le skill, l'agent répond déjà en 59 mots environ (45-70) quand on lui demande d'être bref ; avec le skill, 52 mots (39-64), et avec la version en une phrase, 54. L'écart de 7 mots reste dans la variabilité d'une exécution à l'autre. Aucun groupe n'a utilisé d'ouverture ou de conclusion de remplissage ; les 18 réponses ont toutes conservé le code, les commandes et les faits clés.
• La rétention des faits était identique : 3 à 5 des 5 faits techniques requis par réponse dans chaque groupe (part des faits requis conservés : 87% témoin, 80% une phrase, 87% skill). Le fait que les agents omettaient souvent (qu'une mise à jour d'état re-rend le composant et relance l'effet) était omis à parts égales par les trois groupes. Le point « ne pas rebaser une branche partagée » a été détecté par notre vérification dans 1 réponse témoin sur 2, 0 sur 2 pour la phrase unique et 1 sur 2 pour le skill ; dans les réponses que nous avons lues, toutes recommandaient merge et réservaient rebase au travail privé ou non publié, donc ces échecs tiennent en partie à la formulation.
• Le skill a été lu dans 6/6 exécutions parce que le prompt contient sa phrase de déclenchement. Il coûte 31k tokens par exécution contre 14k (2.2x), parce que l'agent charge le skill et exécute deux commandes pour le lire avant de répondre à une question qu'il pouvait traiter directement. Le prompt d'une phrase coûte autant que le témoin.
• À la lecture des réponses, le style est identique : réponse d'abord, fragments, un court bloc de code. Nous n'avons pas pu distinguer les réponses avec skill de celles du témoin.

Scores par dimension

Limites de ce test

• Le test mesure le skill par-dessus une demande explicite « be brief ». L'usage réel du skill est persistant : il reste actif pendant toute une session, si bien qu'on n'a jamais à répéter la demande, ce que ce test à trois questions n'exerce pas.
• Le coût en tokens compté ici est un chargement unique du skill par conversation ; sur une longue session avec quelques mots gagnés par réponse, il pourrait s'amortir ; nous ne l'avons pas mesuré.
• Seules des réponses de chat à trois questions techniques ont été vérifiées ; les messages de commit, les commentaires de revue de code et les longues sessions d'agent (où le skill a d'autres règles) n'ont pas été testés.
• Les hooks, la statusline et les autres skills caveman du dépôt n'ont pas été installés ni exécutés.
• 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é

Ajouté à une simple demande « be brief », caveman n'a pas raccourci ni dégradé les réponses de façon mesurable, et son chargement a doublé les tokens d'une réponse courte. Si vous voulez un agent laconique sur toute une session sans le redemander à chaque fois, le skill le fait ; si vous avez seulement besoin de brièveté sur une question, dites-le dans le prompt.