Claude-Code-Plugin, das CLAUDE.md-Regeln zu Hooks „kompiliert“

Hallo, ich bin ein Entwickler, der Claude Code jeden Tag nutzt. Je größer CLAUDE.md wurde, desto mehr haben mich zwei Dinge gestört.

1. Die Regeln werden zu Sitzungsbeginn (t=0) komplett geladen, obwohl der Moment, in dem sie wirklich gebraucht werden, oft erst Dutzende Turns später kommt. Wenn sich Kontext ansammelt und einmal kompaktifiziert wurde, werden explizite Regeln zu einem verschwommenen Hintergrund degradiert.
2. Referenzdokumente wie @docs/pr-rules.md zahlen in jeder Session Token im Voraus, obwohl nur ein Teil der Sessions tatsächlich PRs erstellt.

Deshalb habe ich ein Plugin gebaut, das Regeln nicht als „Deklaration am Anfang der Session“, sondern als „an Aktionen gebundene Event-Listener“ kompiliert.

/nunchi:compile extrahiert Regeln aus CLAUDE.md und Referenzdokumenten und erzeugt daraus Regeldateien mit Triggern (Tool + regulärer Ausdruck). Der PreToolUse-Hook liest das Originaldokument dann unmittelbar vor Aktionen wie gh pr create an Ort und Stelle ein und liefert es aus. Wenn eine Kompaktifizierung durchgelaufen ist, setzt der SessionStart-Hook den Auslieferungsstatus zurück, damit beim nächsten Trigger erneut ausgeliefert wird (erneute Auslieferung gemessen 5/5). Alle Auslieferungen werden als JSONL protokolliert, und mit /nunchi:report kann man sehen, „welche Regel wann ausgelöst wurde und was sie eingespart hat“.

Die Kennzahlen sind alle als vorregistrierte Experimente im Repo veröffentlicht.

• Token zu Sitzungsbeginn: Nachdem 8 Regeldokumente (~76 KB) aus @import entfernt wurden, sank die Zahl von 79.683 auf 45.808 (−42,5 %, ~34k Token). Dokumentkosten fallen nur in Sessions an, in denen die jeweilige Aktion tatsächlich ausgelöst wurde.
• Regelverstöße nach Kompaktifizierung: Im Baseline-Setup (nur CLAUDE.md) trat in 1 von 3 Läufen ein Verstoß auf; es war der erste im gesamten Experiment beobachtete Verstoß — und genau an dieser Stelle handelte es sich um eine „von der Kompaktifizierung verworfene Regel aus einem @-Referenzdokument“. Da jedoch das vorregistrierte Gate nicht überschritten wurde, behaupte ich nicht, dass „JIT die Compliance erhöht“ — das ist noch nicht validiert, und im README steht es auch so.
• Kompilierungsqualität: Bei 12 realen CLAUDE.md-Dateien aus freier Wildbahn (airflow, next.js, supabase usw., 166 KB) waren Formatvalidität 100 % und Halluzinationen 0. Der Recall ist mit 35 % gegenüber einem adversarialen Gold-Standard niedrig; das wird nicht verschwiegen, sondern als Issue verfolgt.
• Kompatibilität mit koreanischen Dokumenten: Bei 4 koreanischen CLAUDE.md-Dateien aus freier Wildbahn (einschließlich pinpoint) gab es 0 Formatverstöße, 0 Überextraktion und 0 Halluzinationen; die Intensität verbotener Formulierungen („niemals direkt committen“) wurde zu 88 % korrekt beurteilt. Es gibt auch einen Schreibguide für alle, die CLAUDE.md auf Koreanisch verfassen.

Unterschied zu bestehenden Ansätzen: Path-scoped rules werden durch „Datei lesen“ ausgelöst, nunchi hingegen durch „Aktionen“ (beides ist so entworfen, dass es nebeneinander bestehen kann). Context Mode/RTK-artige Ansätze sind Werkzeuge, die in den Kontext eingehende Ausgaben komprimieren; nunchi komprimiert nicht, sondern plant den Zeitpunkt der Auslieferung. Die Token-Einsparung ist ein Nebeneffekt, entscheidend ist, dass Regeln unmittelbar vor einer Aktion sicher im Kontext vorhanden sind und sich das per Log nachweisen lässt.

Derzeit bin ich selbst der einzige reale Nutzer, daher brauche ich Daten dazu, wie es in anderen Workflows funktioniert (Monorepos, Teams in anderen Sprachräumen, große CLAUDE.md). Die Installation besteht aus zwei Zeilen:

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

Zu Stellen, an denen die Trigger-Inferenz falsch liegt, zu Regeltypen, die sich per regulärem Ausdruck nicht erfassen lassen, oder dazu, was ihr im Report zusätzlich sehen möchtet — ich freue mich über jedes Feedback.