CyrilLeMat/temper-skills

Temper-Skills (Bibliotheksmodus)

Verwandle die Entscheidungslogik eines Agenten-Skills oder Prompts in deterministischen Python-Code – null LLM-Aufrufe zur Inferenzzeit –, indem du die installierte temper-skills CLI steuerst. Du orchestrierst die CLI und gibst ihre Ausgabe weiter; die Bibliothek erledigt das Tempern. Du schreibst den Entscheidungsbaum nie selbst.

Verwende diesen Skill, wenn du kein natives Subagenten-/Task-Primitiv hast, um die Schleife selbst auszuführen. Verwende innerhalb von Claude Code den Subagenten-Modus-Skill (er läuft schlüssellos mit einem Live-Panel). Dieser Modus greift stattdessen auf die CLI zurück.

Wann verwenden

• Ein .md-Skill, System-Prompt oder Playbook enthält Routing-/Entscheidungslogik (Wenn-Dann-Dann über strukturierte Eingaben), die testbar, in einem PR diffbar oder resistent gegenüber Modellaktualisierungen sein sollte.
• Geeignet: Ticket-Routing, Klassifikationsregeln, Berechtigungsprüfungen – kategorische Entscheidungen über vorab berechenbare Merkmale.
• Nicht geeignet: kontinuierliche Bewertung, Textgenerierung oder Logik ohne Dokumentation, die das Modell erreichen kann.

Unverhandelbare Regeln

1. Rufe die Bibliothek immer über ihre CLI auf. Implementiere die Entscheidungslogik niemals in natürlicher Sprache neu als Ersatz für die Ausführung.
2. Überspringe niemals die Schemaratifizierung. Das von dir genehmigte Schema ist der naive Startpunkt, den die Schleife dann ko-evolviert (der schema_critic erweitert es, die Earn-a-Branch-Wächter beschneiden es), sodass ein stiller Extraktionsfehler im Startpunkt trotzdem alles vergiftet. Verwende die dateibasierte Absicherung unten (--propose-schema), auch wenn kein Terminal angeschlossen ist. Überprüfe das ko-evolvierte Schema und alle schema gaps / schema grew-Hinweise, die die CLI am Ende ausgibt.
3. Installiere niemals stillschweigend. Wenn die Absicherung (Schritt 0) meldet, dass die Bibliothek oder ein Backend fehlt, frage den Benutzer, bevor du pip install ausführst oder seine Umgebung änderst.
4. Behaupte niemals, der Baum sei „korrekt“ – nur, dass er deterministisch und auditierbar ist. Korrektheit liegt beim Benutzer, festgelegt durch ratifizierte Beispiele (validate, Schritt 4).
5. Gib die Absicherungen und Entscheidungen der CLI wörtlich weiter – Prüfungsurteil, Persona-Panels, Grauzonen, Fälle, die auf Ratifizierung warten. Fasse sie nicht zusammen.

Schritt 0 – Installation + Backend prüfen

Führe python scripts/check_install.py aus und verzweige anhand des Exit-Codes:

• 0 – bereit, fahre fort.
• 10 – installiert, aber kein Modell-Backend. Sage dem Benutzer: temper-skills benötigt ein Backend – eine angemeldete claude- oder opencode-CLI oder ANTHROPIC_API_KEY in der Umgebung. Frage, wie sie eines bereitstellen möchten. Fahre nicht fort, bis ein Backend existiert.
• 11 – nicht installiert. Frage: „temper-skills ist nicht installiert. Jetzt installieren? (pip install temper-skills)“ Installiere nur nach expliziter Bestätigung.

Schritt 1 – Triage mit guide (hierher führen)

Finde die .md-Datei oder den Prompt mit der Entscheidungslogik (bestätige den Pfad mit dem Benutzer, falls nicht eindeutig), dann führe den Ein-Befehl-Rundgang aus:

temper-skills guide <pfad/zu/skill.md> --json

Wenn der Benutzer auf ein Verzeichnis zeigt (eine Skill-Bibliothek), durchsuche es, anstatt eine Datei zu führen – das Audit ist ein Bericht, den es wert ist, weitergegeben zu werden:

temper-skills audit <verz> --json --report audit.md

Gib die sortierten Ergebnisse weiter (das JSON ist eine Liste von Pro-Skill-Berichten, zuerst die umsetzbarsten) und biete an, die erste Wahl zu guiden. audit.md ist eine teilbare Markdown-Version für einen PR.

Übergib immer --json. guide und ingest geben dann ein maschinenlesbares Manifest auf stdout aus und senden die menschlichen Rich-Panels an stderr – lies das Manifest, scrapte nicht die Panels. Das Manifest von guide ist:

{ "audit": { "verdict": "...", "recommended_action": "...", ... },
  "action_taken": "temper|decompose|...",
  "status": "compiled|stopped_for_ratification|action_not_auto_run",
  "final_skill_path": "...", "artifacts": ["..."] }

guide auditiert den Skill, folgt dann der recommended_action. Gib das Prüfungsurteil und die Aktion an den Benutzer weiter:

• temper – eine baumförmige Entscheidung. guide tempert sie (schnell); status: compiled.
• decompose – ein Ablauf (≥2 Entscheidungen). guide gibt pro Entscheidung Schemas aus und stoppt; status: stopped_for_ratification.
• externalize_data / build_normalizer / delegate_prose – keine Temper-Aufgaben. status: action_not_auto_run; gib den Aktionshinweis weiter und stoppe.

guide ist der Rundgang: es führt das quick-Profil aus und akzeptiert automatisch das abgeleitete Schema. Das ist in Ordnung für „Zeig mir, was das tut“, aber für einen Baum, auf den der Benutzer sich verlassen wird, gehe zu Schritt 2, damit das Schema ratifiziert ist.

Schritt 2 – Einen dauerhaften Baum erstellen (ratifizierter Ablauf)

2a. Schema entwerfen und STOP für Ratifizierung

temper-skills ingest <pfad/zu/skill.md> --propose-schema --json

Dies schreibt schema.proposed.py und stoppt – die Schleife läuft nie mit einem nicht ratifizierten Schema. Das JSON auf stdout gibt dir {proposed_schema_path, fn_name, features:[{name,type,description}], constraints}. Zeige dem Benutzer die vorgeschlagenen Merkmale und frage genau eines: Diese Merkmale akzeptieren oder Liste bearbeiten? Wende seine Änderungen an schema.proposed.py an.

Frage den Benutzer hier nichts anderes – nicht nach Merkmalsbreite, nicht danach, welche Zweige behalten werden sollen. Das Beschneiden ist Aufgabe der Schleife (der Overengineering-Kritiker), nicht des Benutzers.

2b. Gegen das ratifizierte Schema kompilieren

temper-skills ingest <pfad/zu/skill.md> \
  --schema schema.proposed.py \
  --profile standard \
  --json

Wähle das Profil mit dem Benutzer – quick | standard | audit-grade, Standard standard; siehe references/profiles.md vor der Empfehlung. --json bedeutet nicht-interaktiv: die Schleife läuft bis zur Konvergenz (sie kann nicht für eine rundenweise Absicherung anhalten, wenn sie so gesteuert wird – diese Absicherung ist ein menschliches Terminal-Feature) und gibt das Ergebnis-Manifest auf stdout aus. Lies das, scrapte nicht die Panels. (--require-fit bricht früh mit Exit 3 ab, wenn das Prüfungsurteil skip ist; füge es hinzu, um zu vermeiden, dass die Schleife bei einem schlechten Fit läuft.)

2c. Wenn die Aktion decompose war

Ein Ablauf muss zuerst aufgeteilt werden; tempere jede Entscheidung separat:

temper-skills decompose <pfad/zu/skill.md> --temper-each --out-dir out/

Dies gibt ein Schema pro Entscheidung aus und stoppt zur Ratifizierung. Zeige die Schemas an, lass den Benutzer sie bearbeiten, führe dann denselben Befehl erneut aus, um jede in einen Baum plus den Orchestrator-Skill zu kompilieren (--yes-unratified überspringt den Stopp – vermeide es, es sei denn, der Benutzer fragt danach).

Schritt 3 – Artefakte melden (aus dem Manifest)

Das ingest --json-Manifest ist die Quelle der Wahrheit – lies diese Felder, scrappe nicht:

{ "tree_path": "...", "tempered_skill_path": "...",
  "validation_dataset_path": "..." , "validation_case_count": 0,
  "gray_zones": [{"node": 1, "condition": "...", "note": "..."}],
  "features": ["..."], "node_count": 0, "profile": "...", "cost_usd": 0.0 }

Präsentiere dem Benutzer alle drei Artefakte:

• tree_path – der Entscheidungsbaum: importiert nichts, null LLM-Aufrufe zur Inferenzzeit, mit einem Header generated_at + Modell und Kommentaren zur Herkunft pro Knoten;
• tempered_skill_path – die getemperte skill.md: der ursprüngliche Skill, der umgeschrieben wurde, um den eingefrorenen Baum aufzurufen, anstatt neu zu entscheiden. Die Hälfte des Ergebnisses; verwerfe es nicht;
• validation_dataset_path – die festgeschriebene .validation.jsonl, die die Schleife für ihre Grauzonen erstellt hat, die auf Ratifizierung wartet (validation_case_count). Zeilen mit "agrees": false sind die wertvollsten Uneinigkeiten, über die der Benutzer entscheiden soll. Die Verhaltenssperrtests daneben (test_<stamm>.py) bleiben grün; nur ratifizierte Labels können einen Test rot machen.

Teile dem Benutzer die Pfade, das Profil, die cost_usd und die gray_zones mit. Wiederhole Regel 4: deterministisch und auditierbar, nicht „korrekt“.

Schritt 4 (optional) – In CI fixieren

Sobald der Benutzer einen beschrifteten Satz ratifiziert hat, validiere den Baum dagegen:

temper-skills validate decision_tree.generated.py ratified.json --min-agreement 1.0

Exit ungleich Null bei Uneinigkeit – das fixiert den Baum in CI. Jede Uneinigkeit ist entweder ein Baumfehler oder ein falsch beschriftetes Beispiel; gib sie zur Freigabe weiter.

Referenz

Siehe references/profiles.md für Runden / Konvergenz / Persona-Panel / Kosten pro Profil, bevor du eines empfiehlst.

Niemals

• Schreibe niemals die Logik des Baums in natürlicher Sprache, anstatt die Bibliothek auszuführen.
• Überspringe niemals die Schemaratifizierung, selbst in einer quick-Demo (quick lässt Herkunftskommentare weg, nicht die Absicherung).
• Installiere oder ändere niemals die Umgebung ohne explizite Bestätigung.
• Behaupte niemals, der generierte Baum sei „korrekt“.