CyrilLeMat/temper-skills

Temper-Skills (mode bibliothèque)

Transformez la logique décisionnelle d'un skill d'agent ou d'un prompt en Python déterministe — zéro appel LLM à l'inférence — en pilotant la CLI temper-skills installée. Vous orchestrez la CLI et relayez sa sortie ; la bibliothèque effectue le tempering. Vous n'écrivez jamais l'arbre de décision vous-même.

Utilisez ce skill lorsque vous n'avez pas de primitive subagent/Tâche native pour exécuter la boucle vous-même. Dans Claude Code, préférez le skill en mode subagent (il s'exécute sans clé, avec un panneau en direct). Ce mode utilise la CLI en sous-processus.

Quand l'utiliser

• Un skill .md, un prompt système ou un playbook contient une logique de routage/décision (si-ceci-alors-cela sur des entrées structurées) qui doit être testable, différentiable dans une PR, ou résistante aux mises à jour de modèle.
• Bon cas d'usage : routage de tickets, règles de classification, vérifications d'éligibilité — décisions catégorielles sur des caractéristiques pré-calculables.
• Pas adapté : notation continue, génération de texte, ou logique sans documentation accessible au modèle.

Règles non négociables

1. Appelez toujours la bibliothèque via sa CLI. Ne réimplémentez jamais la logique décisionnelle en langage naturel comme substitut à son exécution.
2. Ne sautez jamais la ratification du schéma. Le schéma que vous approuvez est la graine naïve que la boucle co-évolue ensuite (le schema_critic l'agrandit, la garde « gagne-une-branche » l'élague), donc une erreur d'extraction silencieuse dans la graine empoisonne tout. Utilisez la porte basée sur fichier ci-dessous (--propose-schema), même sans terminal attaché. Examinez le schéma co-évolué et les éventuelles notes schema gaps / schema grew que la CLI affiche à la fin.
3. N'installez jamais silencieusement. Si la porte (Étape 0) signale que la bibliothèque ou un backend est manquant, demandez à l'utilisateur avant d'exécuter pip install ou de modifier son environnement.
4. Ne prétendez jamais que l'arbre est "correct" — seulement qu'il est déterministe et vérifiable. La correction relève de l'utilisateur, établie par des exemples ratifiés (validate, Étape 4).
5. Relayez les portes et verdicts de la CLI textuellement — verdict d'audit, panneaux des évaluateurs, zones grises, cas en attente de ratification. Ne les résumez pas.

Étape 0 — Vérifier l'installation et le backend

Exécutez python scripts/check_install.py et bifurquez selon le code de sortie :

• 0 — prêt, continuez.
• 10 — installé mais aucun backend de modèle. Dites à l'utilisateur : temper-skills nécessite un backend — une CLI claude ou opencode connectée, ou ANTHROPIC_API_KEY dans l'environnement. Demandez comment il souhaite en fournir un. Ne continuez pas tant qu'un backend n'existe pas.
• 11 — non installé. Demandez : "temper-skills n'est pas installé. L'installer maintenant ? (pip install temper-skills)" N'installez que sur confirmation explicite.

Étape 1 — Triage avec guide (point de départ)

Trouvez le fichier .md ou le prompt contenant la logique décisionnelle (confirmez le chemin avec l'utilisateur si ambigu), puis exécutez la visite guidée en une commande :

temper-skills guide <chemin/vers/skill.md> --json

Si l'utilisateur pointe un répertoire (une bibliothèque de skills), parcourez-le au lieu de guider un seul fichier — l'audit est un rapport qui mérite d'être relayé en soi :

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

Relayez les résultats classés (le JSON est une liste de rapports par skill, les plus actionnables en premier) et proposez de guider le premier choix. audit.md est une version Markdown partageable pour une PR.

Passez toujours --json. guide et ingest émettent alors un manifeste lisible par machine sur stdout et envoient les panneaux Rich humains sur stderr — lisez le manifeste, ne scrapez pas les panneaux. Le manifeste de guide est :

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

guide audite le skill, puis suit recommended_action. Relayez le verdict d'audit et l'action à l'utilisateur :

• temper — une décision en forme d'arbre. guide la tempere (rapide) ; status: compiled.
• decompose — un flux (≥2 décisions). guide émet un schéma par décision et s'arrête ; status: stopped_for_ratification.
• externalize_data / build_normalizer / delegate_prose — pas des tâches de tempering. status: action_not_auto_run ; relayez l'indication d'action et arrêtez.

guide est la visite guidée : il exécute le profil quick et accepte automatiquement le schéma inféré. C'est acceptable pour "montre-moi ce que ça fait", mais pour un arbre sur lequel l'utilisateur comptera, passez à l'Étape 2 pour que le schéma soit ratifié.

Étape 2 — Produire un arbre stable (flux ratifié)

2a. Rédiger le schéma et S'ARRÊTER pour ratification

temper-skills ingest <chemin/vers/skill.md> --propose-schema --json

Ceci écrit schema.proposed.py et s'arrête — la boucle ne s'exécute jamais sur un schéma non ratifié. Le JSON sur stdout vous donne {proposed_schema_path, fn_name, features:[{name,type,description}], constraints}. Montrez à l'utilisateur les caractéristiques proposées et demandez une seule chose : accepter ces caractéristiques, ou modifier la liste ? Appliquez ses modifications à schema.proposed.py.

Ne demandez rien d'autre à l'utilisateur ici — pas l'étendue des caractéristiques, pas quelles branches conserver. L'élagage est le travail de la boucle (le critique de surentraînement), pas celui de l'utilisateur.

2b. Compiler avec le schéma ratifié

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

Choisissez le profil avec l'utilisateur — quick | standard | audit-grade, par défaut standard ; consultez references/profiles.md avant de recommander. --json implique non-interactif : la boucle s'exécute jusqu'à convergence (elle ne peut pas s'arrêter pour une porte par tour lorsqu'elle est pilotée ainsi — cette porte est une fonctionnalité de terminal humain) et émet le manifeste de résultat sur stdout. Lisez-le, ne scrapez pas les panneaux. (--require-fit se termine tôt avec le code 3 si le verdict d'audit est skip ; ajoutez-le pour éviter de gaspiller la boucle sur un mauvais candidat.)

2c. Si l'action était decompose

Un flux doit être d'abord scindé ; temperez chaque décision séparément :

temper-skills decompose <chemin/vers/skill.md> --temper-each --out-dir out/

Ceci émet un schéma par décision et s'arrête pour ratification. Présentez les schémas, permettez à l'utilisateur de les modifier, puis réexécutez la même commande pour compiler chacun en un arbre plus le skill orchestrateur (--yes-unratified ignore l'arrêt — à éviter sauf si l'utilisateur le demande).

Étape 3 — Signaler les artefacts (depuis le manifeste)

Le manifeste ingest --json est la source de vérité — lisez ces champs, ne scrapez pas :

{ "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ésentez les trois artefacts à l'utilisateur :

• tree_path — l'arbre de décision : n'importe rien, zéro appel LLM à l'inférence, avec un en-tête generated_at + modèle et des commentaires de provenance par nœud ;
• tempered_skill_path — le skill.md temperé : le skill original réécrit pour appeler l'arbre gelé au lieu de re-décider. La moitié du livrable ; ne le laissez pas tomber ;
• validation_dataset_path — le fichier .validation.jsonl validé que la boucle a construit pour ses zones grises, en attente de ratification (validation_case_count). Les lignes avec "agrees": false sont les désaccords les plus importants sur lesquels l'utilisateur doit trancher. Les tests de verrouillage de comportement à côté (test_<stem>.py) restent verts ; seules les étiquettes ratifiées peuvent faire passer un test au rouge.

Indiquez à l'utilisateur les chemins, le profil, le cost_usd et les gray_zones. Rappelez la règle 4 : déterministe et vérifiable, pas "correct".

Étape 4 (optionnelle) — Verrouiller dans l'IC

Une fois que l'utilisateur a ratifié un ensemble étiqueté, validez l'arbre contre celui-ci :

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

Code de sortie non nul en cas de désaccord — c'est ce qui verrouille l'arbre dans l'IC. Chaque désaccord est soit un bogue de l'arbre, soit un exemple mal étiqueté ; relayez-les pour approbation.

Référence

Consultez references/profiles.md pour le nombre de tours / convergence / panneau d'évaluateurs / coût par profil avant d'en recommander un.

Ne jamais

• Ne jamais écrire la logique de l'arbre en langage naturel au lieu d'exécuter la bibliothèque.
• Ne jamais sauter la ratification du schéma, même dans une démo quick (quick supprime les commentaires de provenance, pas la porte).
• Ne jamais installer ou modifier l'environnement sans confirmation explicite.
• Ne jamais prétendre que l'arbre généré est "correct".