Rules Distill
Scannt installierte Skills, extrahiert übergreifende Prinzipien, die in mehreren Skills vorkommen, und destilliert sie in Regeln – durch Anhängen an bestehende Regeldateien, Überarbeiten veralteter Inhalte oder Erstellen neuer Regeldateien.
Wendet das Prinzip "deterministische Sammlung + LLM-Urteil" an: Skripte sammeln Fakten erschöpfend, dann liest ein LLM den vollständigen Kontext quer und erstellt Urteile.
Verwendungszweck
- Regelmäßige Regelwartung (monatlich oder nach Installation neuer Skills)
- Nach einer Skill-Bestandsaufnahme, die Muster zeigt, die zu Regeln werden sollten
- Wenn Regeln im Vergleich zu den verwendeten Skills unvollständig erscheinen
Funktionsweise
Der Rules-Distillation-Prozess durchläuft drei Phasen:
Phase 1: Inventarisierung (Deterministische Sammlung)
1a. Skill-Inventar sammeln
bash ~/.claude/skills/rules-distill/scripts/scan-skills.sh
1b. Regelindex sammeln
bash ~/.claude/skills/rules-distill/scripts/scan-rules.sh
1c. Dem Benutzer präsentieren
Rules Distillation — Phase 1: Inventory
────────────────────────────────────────
Skills: {N} Dateien gescannt
Rules: {M} Dateien ({K} Überschriften indiziert)
Fahre mit der Queranalyse fort...
Phase 2: Querauswertung, Abgleich & Urteil (LLM-Urteil)
Extraktion und Abgleich werden in einem einzigen Durchlauf zusammengefasst. Regeldateien sind klein genug (~800 Zeilen gesamt), dass der vollständige Text dem LLM bereitgestellt werden kann – keine grep-Vorfilterung erforderlich.
Batch-Verarbeitung
Gruppiere Skills in thematische Cluster basierend auf ihren Beschreibungen. Analysiere jedes Cluster in einem Subagenten mit dem vollständigen Regeltext.
Batch-übergreifender Merge
Nach Abschluss aller Batches werden Kandidaten batch-übergreifend zusammengeführt:
- Dedupliziere Kandidaten mit gleichen oder sich überschneidenden Prinzipien
- Überprüfe die Anforderung "2+ Skills" erneut anhand von Belegen aus allen Batches – ein Prinzip, das in 1 Skill pro Batch, aber insgesamt in 2+ Skills gefunden wurde, ist gültig
Subagenten-Prompt
Starte einen allgemeinen Agenten mit dem folgenden Prompt:
Du bist ein Analyst, der Skills querliest, um Prinzipien zu extrahieren, die zu Regeln hochgestuft werden sollten.
## Eingabe
- Skills: {vollständiger Text der Skills in diesem Batch}
- Bestehende Regeln: {vollständiger Text aller Regeldateien}
## Extraktionskriterien
Nimm einen Kandidaten NUR dann auf, wenn ALLE diese Bedingungen zutreffen:
1. **Kommt in 2+ Skills vor**: Prinzipien, die nur in einem Skill gefunden werden, sollten in diesem Skill bleiben
2. **Handlungsorientierte Verhaltensänderung**: Kann als "mache X" oder "mache nicht Y" formuliert werden – nicht "X ist wichtig"
3. **Klares Verletzungsrisiko**: Was schiefgeht, wenn dieses Prinzip ignoriert wird (1 Satz)
4. **Nicht bereits in Regeln enthalten**: Überprüfe den vollständigen Regeltext – einschließlich Konzepten, die mit anderen Worten ausgedrückt werden
## Abgleich & Urteil
Vergleiche jeden Kandidaten mit dem vollständigen Regeltext und weise ein Urteil zu:
- **Append (Anhängen)**: Zu einem bestehenden Abschnitt einer bestehenden Regeldatei hinzufügen
- **Revise (Überarbeiten)**: Bestehender Regelinhalt ist ungenau oder unzureichend – schlage eine Korrektur vor
- **New Section (Neuer Abschnitt)**: Einen neuen Abschnitt zu einer bestehenden Regeldatei hinzufügen
- **New File (Neue Datei)**: Eine neue Regeldatei erstellen
- **Already Covered (Bereits abgedeckt)**: Ausreichend in bestehenden Regeln abgedeckt (auch wenn anders formuliert)
- **Too Specific (Zu spezifisch)**: Sollte auf Skill-Ebene bleiben
## Ausgabeformat (pro Kandidat)
```json
{
"principle": "1-2 Sätze in der Form 'mache X' / 'mache nicht Y'",
"evidence": ["skill-name: §Abschnitt", "skill-name: §Abschnitt"],
"violation_risk": "1 Satz",
"verdict": "Append / Revise / New Section / New File / Already Covered / Too Specific",
"target_rule": "Dateiname §Abschnitt, oder 'new'",
"confidence": "high / medium / low",
"draft": "Entwurfstext für Append/New Section/New File-Urteile",
"revision": {
"reason": "Warum der bestehende Inhalt ungenau oder unzureichend ist (nur Revise)",
"before": "Aktueller Text, der ersetzt werden soll (nur Revise)",
"after": "Vorgeschlagener Ersatztext (nur Revise)"
}
}
```
## Ausschließen
- Offensichtliche, bereits in Regeln enthaltene Prinzipien
- Sprach-/Framework-spezifisches Wissen (gehört in sprachspezifische Regeln oder Skills)
- Code-Beispiele und Befehle (gehören in Skills)
Urteilsreferenztabelle
| Urteil | Bedeutung | Dem Benutzer präsentiert |
|---|---|---|
| Append | Zu bestehendem Abschnitt hinzufügen | Ziel + Entwurf |
| Revise | Ungenauen/unzureichenden Inhalt korrigieren | Ziel + Grund + Vorher/Nachher |
| New Section | Neuen Abschnitt zu bestehender Datei hinzufügen | Ziel + Entwurf |
| New File | Neue Regeldatei erstellen | Dateiname + vollständiger Entwurf |
| Already Covered | In Regeln abgedeckt (möglicherweise anders formuliert) | Grund (1 Zeile) |
| Too Specific | Sollte in Skills bleiben | Link zum relevanten Skill |
Qualitätsanforderungen an Urteile
# Gut
Append to rules/common/security.md §Eingabevalidierung:
"Behandle LLM-Ausgaben, die im Speicher oder in Wissensdatenbanken gespeichert werden, als nicht vertrauenswürdig – bereinige beim Schreiben, validiere beim Lesen."
Belege: llm-memory-trust-boundary, llm-social-agent-anti-pattern beschreiben beide
angesammelte Prompt-Injection-Risiken. Aktuelle security.md deckt nur
menschliche Eingabevalidierung ab; die Vertrauensgrenze für LLM-Ausgaben fehlt.
# Schlecht
Append to security.md: LLM-Sicherheitsprinzip hinzufügen
Phase 3: Benutzerüberprüfung & Ausführung
Zusammenfassungstabelle
# Rules Distillation Report
## Zusammenfassung
Gescannte Skills: {N} | Regeln: {M} Dateien | Kandidaten: {K}
| # | Prinzip | Urteil | Ziel | Konfidenz |
|---|---------|--------|------|-----------|
| 1 | ... | Append | security.md §Eingabevalidierung | hoch |
| 2 | ... | Revise | testing.md §TDD | mittel |
| 3 | ... | New Section | coding-style.md | hoch |
| 4 | ... | Too Specific | — | — |
## Details
(Details pro Kandidat: Belege, Verletzungsrisiko, Entwurfstext)
Benutzeraktionen
Der Benutzer antwortet mit Nummern für:
- Approve (Genehmigen): Entwurf unverändert auf Regeln anwenden
- Modify (Ändern): Entwurf vor Anwendung bearbeiten
- Skip (Überspringen): Diesen Kandidaten nicht anwenden
Regeln niemals automatisch ändern. Immer Benutzerfreigabe einholen.
Ergebnisse speichern
Speichere Ergebnisse im Skill-Verzeichnis (results.json):
- Zeitstempelformat:
date -u +%Y-%m-%dT%H:%M:%SZ(UTC, Sekundengenauigkeit) - Kandidaten-ID-Format: Kebab-Case abgeleitet vom Prinzip (z. B.
llm-output-trust-boundary)
{
"distilled_at": "2026-03-18T10:30:42Z",
"skills_scanned": 56,
"rules_scanned": 22,
"candidates": {
"llm-output-trust-boundary": {
"principle": "LLM-Ausgabe als nicht vertrauenswürdig behandeln, wenn sie gespeichert oder erneut eingeschleust wird",
"verdict": "Append",
"target": "rules/common/security.md",
"evidence": ["llm-memory-trust-boundary", "llm-social-agent-anti-pattern"],
"status": "applied"
},
"iteration-bounds": {
"principle": "Explizite Abbruchbedingungen für alle Iterationsschleifen definieren",
"verdict": "New Section",
"target": "rules/common/coding-style.md",
"evidence": ["iterative-retrieval", "continuous-agent-loop", "agent-harness-construction"],
"status": "skipped"
}
}
}
Beispiel
End-to-End-Durchlauf
$ /rules-distill
Rules Distillation — Phase 1: Inventory
────────────────────────────────────────
Skills: 56 Dateien gescannt
Rules: 22 Dateien (75 Überschriften indiziert)
Fahre mit der Queranalyse fort...
[Subagenten-Analyse: Batch 1 (Agenten/Meta-Skills) ...]
[Subagenten-Analyse: Batch 2 (Code/Muster-Skills) ...]
[Batch-übergreifender Merge: 2 Duplikate entfernt, 1 Batch-übergreifender Kandidat hochgestuft]
# Rules Distillation Report
## Zusammenfassung
Gescannte Skills: 56 | Regeln: 22 Dateien | Kandidaten: 4
| # | Prinzip | Urteil | Ziel | Konfidenz |
|---|---------|--------|------|-----------|
| 1 | LLM-Ausgabe: Vor Wiederverwendung normalisieren, typüberprüfen, bereinigen | New Section | coding-style.md | hoch |
| 2 | Explizite Abbruchbedingungen für Iterationsschleifen definieren | New Section | coding-style.md | hoch |
| 3 | Kontext an Phasengrenzen verdichten, nicht mitten in der Aufgabe | Append | performance.md §Context Window | hoch |
| 4 | Geschäftslogik von I/O-Framework-Typen trennen | New Section | patterns.md | hoch |
## Details
### 1. LLM-Ausgabevalidierung
Urteil: New Section in coding-style.md
Belege: parallel-subagent-batch-merge, llm-social-agent-anti-pattern, llm-memory-trust-boundary
Verletzungsrisiko: Formatabweichungen, Typkonflikte oder Syntaxfehler in der LLM-Ausgabe lassen nachgelagerte Verarbeitung abstürzen
Entwurf:
## LLM-Ausgabevalidierung
Normalisiere, typüberprüfe und bereinige LLM-Ausgaben vor der Wiederverwendung...
Siehe Skill: parallel-subagent-batch-merge, llm-memory-trust-boundary
[... Details für Kandidaten 2-4 ...]
Genehmigen, ändern oder überspringen Sie jeden Kandidaten per Nummer:
> Benutzer: Genehmige 1, 3. Überspringe 2, 4.
✓ Angewendet: coding-style.md §LLM-Ausgabevalidierung
✓ Angewendet: performance.md §Context Window Management
✗ Übersprungen: Iteration Bounds
✗ Übersprungen: Boundary Type Conversion
Ergebnisse gespeichert in results.json
Designprinzipien
- Was, nicht Wie: Nur Prinzipien extrahieren (Regel-Territorium). Codebeispiele und Befehle bleiben in Skills.
- Rückverlinken: Entwurfstext sollte
Siehe Skill: [Name]-Referenzen enthalten, damit Leser das detaillierte Wie finden können. - Deterministische Sammlung, LLM-Urteil: Skripte garantieren Vollständigkeit; das LLM garantiert kontextuelles Verständnis.
- Anti-Abstraktions-Sicherung: Der 3-stufige Filter (Belege aus 2+ Skills, Handlungsorientierungstest, Verletzungsrisiko) verhindert, dass zu abstrakte Prinzipien in Regeln gelangen.