Plugin de Claude Code que “compila” las reglas de CLAUDE.md en hooks

Hola, soy un desarrollador que usa Claude Code todos los días. A medida que CLAUDE.md crecía, dos cosas me seguían molestando.

1. Las reglas se cargan completas al inicio de la sesión (t=0), pero el momento en que realmente se necesitan llega decenas de turnos después. Cuando el contexto se acumula y pasa una compactación, las reglas explícitas quedan relegadas a un fondo difuso.
2. Los documentos de referencia como @docs/pr-rules.md pagan tokens por adelantado en cada sesión, aunque solo algunas sesiones realmente crean un PR.

Así que creé un plugin que “compila” las reglas no como una “declaración al inicio de la sesión”, sino como “event listeners vinculados a acciones”.

/nunchi:compile extrae reglas de CLAUDE.md y de documentos de referencia, y las convierte en archivos de reglas con triggers (herramienta + expresión regular). Luego, un hook PreToolUse lee y entrega el documento original justo antes de acciones como gh pr create. Cuando pasa una compactación, un hook SessionStart reinicia el estado de entrega para volver a entregarlo en el siguiente trigger (reentrega medida: 5/5). Todas las entregas se registran en JSONL, y con /nunchi:report se puede ver “qué regla se activó cuándo y qué se ahorró”.

Todas las cifras están publicadas en el repo como experimentos prerregistrados.

• Tokens al inicio de la sesión: al quitar 8 documentos de reglas (~76 KB) de @import, bajó de 79,683 a 45,808 (−42.5%, ~34k tokens). El costo de los documentos se paga solo en las sesiones donde la acción correspondiente realmente se activa.
• Incumplimientos de reglas tras compactación: en la línea base (solo CLAUDE.md) ocurrió 1 vez en 3 ejecuciones; fue el primer incumplimiento observado en todo el experimento, y ese punto fue exactamente una “regla dentro de un documento @referenciado que la compactación había descartado”. Sin embargo, como no superó el umbral prerregistrado, no afirmo que “JIT tenga mayor tasa de cumplimiento”: eso aún no está verificado, y así también está escrito en el README.
• Calidad de compilación: en 12 CLAUDE.md reales encontrados en la práctica (airflow, next.js, supabase, etc.; 166 KB), 100% de validez de formato y 0 alucinaciones. El recall fue bajo, 35% frente a un gold adversarial, y tampoco lo oculto: lo estoy siguiendo como issue.
• Compatibilidad con documentación en coreano: en 4 CLAUDE.md reales en coreano (incluido pinpoint), 0 violaciones de formato, 0 sobreextracciones y 0 alucinaciones; 88% de precisión al determinar la fuerza de expresiones prohibitivas (“nunca haga commits directamente”). También hay una guía de redacción para quienes escriben CLAUDE.md en coreano.

Diferencia con enfoques existentes: las path-scoped rules se disparan al “leer archivos”, mientras que nunchi se dispara por “acciones” (están diseñadas para coexistir). Context Mode/RTK y similares son herramientas que comprimen la salida que entra al contexto; nunchi no comprime, sino que agenda el momento de entrega. El ahorro de tokens es un subproducto; lo central es que la regla esté con certeza en el contexto justo antes de la acción, y que eso pueda probarse con logs.

Por ahora, el único usuario real soy yo, así que necesito datos sobre cómo se comporta en otros flujos de trabajo (monorepos, equipos de otros idiomas, CLAUDE.md grandes). La instalación son dos líneas:

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

Puntos donde la inferencia de triggers falle, tipos de reglas que no se capturen con regex, cosas que les gustaría ver más en el reporte: agradeceré cualquier feedback.