Un plugin Claude Code qui « compile » les règles de CLAUDE.md en hooks

Bonjour, je suis développeur et j’utilise Claude Code au quotidien. Plus CLAUDE.md grossissait, plus deux choses me gênaient.

1. Les règles sont chargées d’un bloc au début de la session (t=0), alors que le moment où elles sont réellement nécessaires arrive parfois des dizaines de tours plus tard. Une fois le contexte accumulé et une compaction passée, les règles explicites sont reléguées à un arrière-plan flou.
2. Les documents de référence comme @docs/pr-rules.md coûtent des tokens à l’avance à chaque session, alors que seules certaines sessions créent effectivement une PR.

J’ai donc créé un plugin qui « compile » les règles non pas comme des « déclarations en haut de session », mais comme des « écouteurs d’événements liés à des actions ».

/nunchi:compile extrait les règles de CLAUDE.md et des documents de référence, puis les transforme en fichiers de règles auxquels sont associés des déclencheurs (outil + expression régulière). Un hook PreToolUse lit alors le document source sur place et le livre juste avant une action comme gh pr create. Après une compaction, un hook SessionStart réinitialise l’état de livraison afin que la règle soit livrée à nouveau au prochain déclencheur (relivraison mesurée : 5/5). Toutes les livraisons sont journalisées en JSONL, et /nunchi:report permet de voir « quelle règle s’est déclenchée quand, et ce qu’elle a économisé ».

Tous les chiffres sont publiés dans le dépôt sous forme d’expériences préenregistrées.

• Tokens au démarrage de session : en retirant 8 documents de règles (~76 Ko) des @import, on passe de 79 683 à 45 808 (−42,5 %, ~34k tokens). Le coût des documents n’est payé que dans les sessions où l’action correspondante se déclenche réellement.
• Violations de règles après compaction : dans la baseline (CLAUDE.md seul), 1 violation sur 3 exécutions, la première observée sur l’ensemble de l’expérience — et ce point correspondait exactement à une « règle dans un document @ référencé que la compaction avait supprimé ». Cela dit, le seuil préenregistré n’ayant pas été franchi, je n’affirme pas que « le JIT offre un meilleur taux de conformité » — ce n’est pas encore vérifié, et c’est aussi indiqué dans le README.
• Qualité de compilation : sur 12 CLAUDE.md réels trouvés dans la nature (airflow, next.js, supabase, etc., 166 Ko), 100 % de validité de format, 0 hallucination. Le recall est faible, à 35 % face à un gold adversarial, et je ne le cache pas : c’est suivi comme issue.
• Compatibilité avec les documents en coréen : sur 4 CLAUDE.md réels en coréen (dont pinpoint), 0 violation de format, 0 surextraction, 0 hallucination, et 88 % de justesse dans l’évaluation de l’intensité des formulations d’interdiction (« ne jamais committer directement »). Il existe aussi un guide de rédaction pour les personnes qui écrivent leur CLAUDE.md en coréen.

Différence avec les approches existantes : les path-scoped rules se déclenchent à la « lecture de fichier », tandis que nunchi se déclenche à l’« action » (les deux sont conçus pour coexister). Les outils de type Context Mode/RTK compressent les sorties qui entrent dans le contexte ; nunchi ne compresse pas, il planifie le moment de livraison. La réduction de tokens est un effet secondaire ; l’essentiel est que la règle soit bien dans le contexte juste avant l’action, et que cela puisse être prouvé par les logs.

Pour l’instant, je suis le seul utilisateur réel, donc j’ai besoin de données sur son comportement dans d’autres workflows (monorepos, équipes d’autres langues, gros CLAUDE.md). L’installation se fait en deux lignes :

/plugin marketplace add seob717/nunchi
/plugin install nunchi@nunchi-marketplace

Je serai reconnaissant pour tout retour : les cas où l’inférence des déclencheurs se trompe, les types de règles que les expressions régulières ne capturent pas, ce que vous aimeriez voir en plus dans les rapports, etc.