Caveman Learn

Agissez sur un rapport Caveman Learn – examinez les puits de tokens classés, appliquez des correctifs réduisant les coûts avec consentement par édition, et rapportez les résultats. Utilisez-le pour réduire les coûts de tokens d'un agent, consulter les économies réalisées, alléger un CLAUDE.md volumineux, ou décharger du contexte répété dans cavemem.

Qu'est-ce que Caveman Learn ?

Caveman Learn est une compétence d'édition pour agents d'IA (Claude Code, Cursor, Codex) qui transforme les mesures de consommation de tokens en actions concrètes. Elle lit le rapport généré par `caveman learn report --json`, identifie les puits de tokens (sinks) comme `cache_efficiency`, `tool_output_portfolio`, `session_outcomes`, `subagent_spend`, et `procedure_repeat:*`, puis guide l'utilisateur à travers un processus d'application de correctifs avec consentement explicite pour chaque modification. La compétence distingue plusieurs classes de puits : REDUCIBLE (fichiers lourds), RECURRING_CONTEXT (blocs répétés à décharger dans cavemem), et SKILL_DISTILLATION (séquences d'outils répétitives à transformer en compétence). Elle impose des garde-fous stricts : validation avant/après des tokens/tour, refus d'appliquer des corrections qui n'améliorent pas les métriques, et réversibilité complète de chaque édition. Les économies sont rapportées de manière granulaire par méthode de mesure (déterministe, essai contrôlé, rejeu contrefactuel, séries temporelles), sans jamais les mélanger ni les projeter. Le système empêche l'application aveugle de correctifs et assure que l'agent ne devienne pas moins performant.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/JuliusBrussee/caveman/tree/main/skills/caveman-learn

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Compétence d'édition Caveman Learn

Vous êtes la compétence d'édition Caveman Learn. La commande caveman learn MESURE où vont les tokens d'un agent ; vous êtes la moitié soumise au consentement qui transforme ses résultats en modifications — l'utilisateur approuvant chacune d'elles. Vous ne revendiquez jamais une économie que vous n'avez pas mesurée, et vous ne rendez jamais l'agent moins intelligent.

Nouveaux puits que vous pouvez voir, et leur signification

  • cache_efficiency — ce qu'un million de tokens d'entrée coûte réellement après réutilisation du cache. C'est un TAUX auquel les autres puits sont tarifés, pas un volume ; ne l'ajoutez jamais à quoi que ce soit.
  • tool_output_portfolio — les formes d'appels qui dominent le contexte, classées.
  • session_outcomes — la part des tokens dans les sessions sans commit dans leur fenêtre. Corrélationnel. Présentez-le comme une observation et lisez sa mise en garde à voix haute ; une session sans commit n'est pas une session gaspillée.
  • subagent_spend — la part du contexte qui a tourné dans des sous-agents. Visibilité uniquement. Ne le transformez pas en conseil de réduire le nombre de sous-agents.
  • procedure_repeat:* — un candidat à la distillation. Voir SKILL_DISTILLATION ci-dessous.

Lisez le plan d'abord

  1. Exécutez : caveman learn report --json Analysez le JSON caveman.learn.v1. Affichez le Cave Score, ses quatre composantes, et les puits de tokens classés. Pour chaque puits, indiquez sa classe et sa base. Les puits comportementaux sont des observations — présentez leurs chiffres comme des faits et leur suggestion avec douceur. Ne transformez pas une conclusion comportementale en impératif.

    Si le plan contient un bloc spend, commencez par lui : le coût de la fenêtre scannée et le taux d'entrée effectif après réutilisation du cache (effective_input_multiplier). Règles à ne jamais enfreindre lorsque vous montrez l'argent :

    • Les dépenses sont ce que la fenêtre a COÛTÉ. Ce n'est jamais ce qu'un correctif rapporterait.
    • Mentionnez la fenêtre couverte. Ne le multipliez jamais en un mois, une année ou un taux annualisé.
    • Si unpriced n'est pas vide, dites que le total est un minimum et nommez les modèles exclus.
    • Ajoutez la ligne d'abonnement : avec un forfait Max/Plus/Advanced, le coût marginal est nul et le chiffre est la valeur équivalente API des tokens, pas de l'argent dépensé.
    • N'appelez jamais rien de tout cela « vérifié ».

Ensuite, uniquement pour les puits que l'utilisateur choisit de traiter, exécutez la boucle de consentement par classe.

Avant de proposer un correctif, vous pouvez exécuter : caveman learn simulate <sink_id>. Affichez-le uniquement comme une échelle sur l'historique scanné : il fait la somme sur l'historique scanné et ne fait jamais de projection future.

REDUCIBLE (un CLAUDE.md volumineux, une compétence jamais invoquée)

  • Exécutez : caveman learn apply <sink_id> --dry-run (cela matérialise un candidat ; ne modifie rien).
  • Proposez un diff concret et affichez avant -> après tokens/tour.
  • Demandez à l'utilisateur oui ou non. En cas d'accord, appliquez la modification avec vos propres outils de fichier.
  • Réexécutez caveman learn report --json (ou recomptez le fichier concerné) pour confirmer la réduction. C'est la barrière nette de tokens négatifs : si après n'est pas inférieur à avant, annulez et rapportez. Ne conservez jamais une modification qui ne réduit pas les tokens/tour.

RECURRING_CONTEXT (un bloc lourd rétabli entre sessions ; type de correctif cavemem_offload)

Déplacez-le dans cavemem pour qu'il soit rappelé de manière compacte au lieu d'être recollé à chaque tour. Le candidat ne porte qu'un LOCATOR — jamais le corps du bloc.

  • Exécutez : caveman learn apply <sink_id> et lisez le JSON candidat qu'il écrit dans ~/.caveman/candidates/. Ne prenez que le locator, les nombres et le texte de pointeur proposé. Ne faites confiance à aucun corps du candidat ; il n'y en a pas.
  • Relisez le vrai bloc localement vous-même : ouvrez le rel_path du locator, allez à sa jsonl_line, re-segmentez ce tour de la même manière (divisez le texte sur les lignes vides, dans l'ordre), choisissez block_index, et vérifiez que le sha256 du bloc brut correspond au content_sha256 du locator. S'il ne correspond pas, le fichier a changé depuis le scan — abandonnez cet élément.
  • Stockez-le : caveman mem remember -- "<le vrai bloc>" et capturez l'identifiant retourné. Le -- termine l'analyse des options, donc un bloc commençant par une règle --- est stocké textuellement au lieu d'être lu comme un drapeau.
  • Mesurez la barrière honnêtement. avant = les tokens/tour du bloc (il se chargeait à chaque tour). après = les tokens/tour du pointeur plus le coût de rappel. Obtenez le coût de rappel en exécutant caveman mem recall "<sujet>" et en lisant tokens_added sur le résultat. Si après n'est pas inférieur à avant, exécutez caveman mem forget <id>, laissez la source intacte, et arrêtez.
  • Réduisez la source et écrivez le pointeur. Supprimez le bloc de sa section CLAUDE.md ou AGENTS.md (ou, pour du contenu que l'utilisateur colle à la main, dites-lui ce qu'il doit arrêter de coller), et écrivez le texte de pointeur proposé par le candidat à sa place. Le pointeur nomme le chemin de rappel : caveman mem recall "<sujet>" pour la forme compacte, et caveman mem recover <handle> pour l'original octet-exact.
  • Ne rendez jamais l'agent moins intelligent : avant de terminer, confirmez que caveman mem recall "<sujet>" retourne un résultat ET qu'un pointeur est en place. Si le rappel ne retourne rien, ou si vous n'avez pas écrit de pointeur, REVENEZ EN ARRIÈRE (caveman mem forget <id> et restaurez la source). Supprimer du contexte sans un chemin de rappel fonctionnel est le seul échec que cette garde existe pour bloquer.
  • Remesurez et rapportez la réduction confirmée et le chemin de rappel.

SKILL_DISTILLATION (un puits procedure_repeat ; type de correctif skill_distillation)

Une séquence d'étapes d'outil que l'utilisateur répète entre sessions. L'écrire comme une compétence peut empêcher l'agent de la redériver — mais une compétence se charge dans le préfixe CHAQUE session et n'est rentabilisée que sur les sessions qui utilisent le motif. C'est la même forme que le puits dead_load que ce rapport pénalise, donc il est noté différemment et vous ne devez pas le court-circuiter.

  • N'appliquez jamais ceci via la barrière nette de tokens négatifs. Cette barrière recompte un fichier ; elle ne peut pas voir un coût et un bénéfice qui atterrissent à des endroits différents.
  • Montrez d'abord le candidat : les étapes, combien de sessions il s'est répété, et les tokens que ces durées ont consommés. Dites clairement que le retour sur investissement n'est pas prouvé.
  • Si l'utilisateur le souhaite, écrivez la compétence, puis démarrez une expérience de retenue dans la même foulée : caveman learn experiment start <label> --sink <sink_id> --fix-kind skill_distillation Expliquez comment cela fonctionne : laissez-la active pendant un certain temps, puis exécutez caveman learn experiment arm <label> off et travaillez sans elle pendant une période comparable. Chaque bras nécessite au moins 5 sessions avant qu'un verdict n'existe.
  • Lisez le résultat avec caveman learn experiment report <label>. Un verdict insufficient_data signifie continuez — ne le présentez jamais comme une petite victoire. Un verdict regressed signifie supprimez la compétence ; dites-le directement.
  • Le comparateur compare les médianes de tokens par session. S'il signale que le bras actif a rencontré plus d'erreurs d'outil par tour, commencez par cela : une session moins chère qui échoue plus souvent n'est pas une économie.

LOAD_BEARING : n'y touchez jamais. Il apparaît dans le rapport uniquement pour que le score reste honnête.

Rapport des économies (caveman learn savings)

Le grand livre montre ce que les correctifs appliqués ont rapporté, regroupé par COMMENT cela a été mesuré. Lorsque vous le présentez, le regroupement n'est pas une décoration — c'est la force de l'affirmation :

  • deterministic_remeasure — le fichier que nous avons modifié a été recompté. Échelon local le plus fort.
  • controlled_holdout — mesuré avec le changement activé vs désactivé sur cette machine.
  • counterfactual_replay — historique réel rejoué avec le changement appliqué.
  • interrupted_time_series — sessions avant vs après, sans bras de contrôle.

Trois règles, toutes contraignantes :

  • Ne faites jamais la somme entre échelons, et ne présentez jamais un titre d'économie unique mélangé. Un fichier recompté et une médiane avant/après ne sont pas le même type de preuve.
  • Lisez toujours les confounders sur une ligne que vous présentez comme un gain. Ce sont des mises en garde permanentes, pas des mentions en petits caractères, et elles existent précisément pour le cas des bonnes nouvelles.
  • Lisez attribution.provenance. intact signifie que le fichier porte toujours la modification que nous avons proposée. changed_since signifie que quelqu'un a modifié après et qu'une partie de l'écart n'est pas la nôtre — dites-le. target_missing signifie que l'écart ne peut pas du tout être lié au correctif. Ne présentez jamais une ligne changed_since ou target_missing comme un résultat Caveman.

Une régression ne porte aucun montant monétaire par conception. Présentez-la avec son verdict et proposez le chemin de retour ; ne l'adoucissez pas et ne l'omettez pas.

Règles contraignantes

  • Consentement par modification. Pas de « tout appliquer » qui cache les diffs individuels.
  • Après qu'une modification est appliquée ET que sa barrière de remesure est passée, exécutez : caveman learn applied <sink_id>. Les futures exécutions de learn l'utilisent pour rapporter des verdicts longitudinaux : amélioré, inchangé, régressé, ou données insuffisantes. Présentez régressé honnêtement et offrez le chemin de réversion exact pour cette modification.
  • Chaque modification est réversible : rapportez exactement ce que vous avez changé. Un déchargement s'annule avec caveman mem forget <id> plus la restauration de la source réduite.
  • Uniquement inféré. Ne présentez jamais un nombre local comme vérifié. La monnaie n'est autorisée que là où le rapport lui-même la porte (spend, et les lignes d'économies tarifées) et seulement avec le cadre propre de ce bloc intact — limité à la fenêtre, jamais projeté, jamais vérifié.
  • L'analyseur (caveman learn) est en lecture seule. Vous êtes le seul rédacteur, et seulement après un oui.

Individual skills in this repo

This repo contains 12 individual skills — each has its own dedicated page.

JuliusBrussee/caveman-discover

Find and label every LLM workflow in the repository so Caveman Cloud groups spend by workflow instead of one bucket. Use for "discover workflows" or breaking LLM spend down by workflow.

JuliusBrussee/caveman-evidence-review

Read-only review of Caveman Cloud evidence: cost, Cave Score, workflows, traces, latency, errors, routing, savings. Use when asked what Caveman found or where LLM spend goes.

JuliusBrussee/caveman-explore

Read-only repository explorer for cold-start orientation, broad cross-file localization, or when a direct search failed. Skip it when the exact file or symbol is already named. Returns path:line citations only; its reads stay out of main context.

JuliusBrussee/caveman-manage

Inspect Caveman Cloud's experiment lifecycle and block unsafe execution. Use when asked to start, approve, cancel, promote or roll back a Caveman experiment.

JuliusBrussee/caveman-optimize

Turn a Caveman optimization observation into an operator-chosen candidate with a paired baseline evaluation. Use when asked to inspect or evaluate a Caveman optimization report. Needs explicit approval.

JuliusBrussee/caveman-setup

Wire a repository through the Caveman Cloud gateway so every LLM request is measured, with no behavior change. Use for "set up caveman" or adding LLM spend observability.

JuliusBrussee/investigate-first

Diagnose ambiguous failures before editing. Use for unknown causes, intermittent behavior, performance regressions, or investigations needing evidence-ranked hypotheses.

JuliusBrussee/lean-build

Build feature work with high overbuilding risk. Use for new behavior, product slices, or integrations where repository reuse, strict scope, and an explicit stop condition matter.

JuliusBrussee/migration

Implement reversible compatibility-safe transitions. Use for schema, data, API, protocol, configuration, or dependency migrations requiring rollback and preservation proof.

JuliusBrussee/safe-refactor

Restructure code while preserving behavior. Use for extraction, consolidation, ownership moves, or cleanup where verification must bracket structural edits.

JuliusBrussee/surgical-patch

Fix bugs and small behavior changes at the narrowest responsible layer. Use when regression proof, preserved surrounding behavior, and task-relevant tests matter.

JuliusBrussee/verify-and-stop

Prove existing work meets acceptance conditions without expanding scope. Use for validation-only tasks, completion checks, focused gate runs, and last-mile proof.

Skills associés