| name | tk-grill |
| description | Interroge l'utilisateur sans relâche sur un plan, un design ou une décision architecturale TricorderKit, en descendant chaque branche de l'arbre de décision une question à la fois, jusqu'à compréhension partagée — puis matérialise le résultat en entrée DEC-NNN routée et journalisée. À utiliser quand l'utilisateur veut stress-tester une décision, « se faire griller » sur un design, instruire un DEC avant de le loguer, ou dès qu'une tâche relève du Risk Guard MEDIUM/HIGH/CRITICAL. Ne PAS utiliser pour le remplissage de fiches de domaine (déléguer aux skills de lookup de domaine) ni pour une simple récupération factuelle. |
tk-grill — Interrogation socratique alignée TricorderKit
Version : 0.1.0 — 2026-06-03
Ancrage : TricorderKit v0.9 · AGENTS.md v0.8 · DEC-016 (routage) · Risk Guard
Origine : adaptation maison de grill-me (mattpocock/skills) — interrogation socratique
réinstrumentée pour produire une décision déterministe, traçable et routée, pas une simple conversation.
🎯 Rôle & déclencheurs
tk-grill prend un plan/design encore flou et le résout branche par branche par interrogation,
chaque question accompagnée d'une réponse recommandée. Contrairement à grill-me générique,
il ne s'arrête pas à « compréhension partagée » : il atterrit sur une entrée DEC-NNN prête à
coller dans .planning/DECISIONS.md, route le livrable (DEC-016) et propose la mise à jour d'état.
Déclencheurs
- Naturels :
grille-moi, grill me, stress-test, instruis ce DEC, poke des trous, challenge ce design
- Commande :
/tk:grill <sujet>
- Automatique : toute tâche évaluée Risk Guard MEDIUM / HIGH / CRITICAL déclenche tk-grill avant exécution.
Ce qu'il N'EST PAS
- ❌ Un outil de recherche factuelle (déléguer aux skills de lookup de domaine).
- ❌ Un générateur de fiches.
- ❌ Un exécutant : il instruit la décision, il ne l'applique pas. L'application reste un acte séparé et explicite.
⚙️ Pré-vol obligatoire (avant la 1re question)
- Lire le contexte décisionnel :
.planning/DECISIONS.md (5 dernières + toute entrée liée au sujet).
→ Si le sujet recoupe un DEC Appliquée ou Révoquée, le signaler immédiatement : on n'instruit pas une décision déjà tranchée (règle « interdiction de recréation »).
- Lire l'état :
.planning/STATE.md (phase active) et .planning/TASKS.md (items pending/in_progress liés).
- Interdiction de recréation : vérifier
plugins/cli-forge/generated/, skills/, plugins/workflow-engine/ — si la chose existe déjà, le grill porte sur l'évolution, pas la création.
- CLI avant LLM : si une CLI
goat/tk répond déjà à la question, l'exécuter au lieu de demander.
- Classer le Risk Guard du sujet (LOW/MEDIUM/HIGH/CRITICAL) — il fixe la profondeur du grill et le gate de sortie.
Si un point est répondable par exploration du repo ou des .planning, explorer au lieu de demander.
🔄 Protocole d'interrogation
Règles dures :
- Une seule question à la fois. Jamais de salve.
- Chaque question porte une réponse recommandée (« Reco : … parce que … »), pour combler le gap, pas seulement le pointer.
- Descendre l'arbre de décision : résoudre les dépendances entre choix une par une, ne pas sauter en aval tant qu'un nœud amont est ouvert.
- Explorer plutôt que demander dès que le repo/.planning contient la réponse.
- S'arrêter quand tous les nœuds de l'arbre sont résolus OU quand l'utilisateur dit « stop / ça suffit / loggue ».
Vagues de grill (ordre canonique TricorderKit)
Adapter au sujet, mais couvrir au minimum ces axes — ce sont les gardes-fous non négociables du projet :
| Vague | Question-noyau | Garde-fou projet |
|---|
| 1. Cadrage | Quel problème exact, et pourquoi maintenant ? Mesure de succès ? | Évite la solution sans problème |
| 2. Existant | Qu'est-ce qui existe déjà (CLI/skill/workflow/DEC) ? | Interdiction de recréation |
| 3. CLI vs LLM | Une CLI déterministe peut-elle le faire ? | CLI avant LLM |
| 4. Contrat | Format de sortie ? Respecte-t-il core/contracts/skill_output.schema.json ? | Output contractuel |
| 5. Routage | Quel dépôt cible (framework générique / repo de domaine) ? | DEC-016 |
| 6. Sûreté | Dry-run prévu ? Réversibilité ? Rollback explicite ? | Dry-run obligatoire |
| 7. Coût | Budget tokens estimé ? Segmentation si > 80 % ? | Token Hygiene |
| 8. Fiabilité | Sources/validation si données externes (2 sources ou primaire) ? | Règles métier du domaine |
| 9. Risque | Niveau Risk Guard final → gate de sortie adapté | Risk Guard |
🚦 Gate de sortie (selon Risk Guard)
- LOW → proposer directement l'entrée DEC + MAJ STATE.
- MEDIUM → confirmation courte de l'utilisateur avant de loguer.
- HIGH → exiger un plan explicite + validation nominative avant toute application ; loguer le DEC en
Statut : Acceptée — application différée.
- CRITICAL → refus d'atterrir seul : escalade, on ne loggue qu'après arbitrage explicite de Sébastien.
📝 Format de sortie (obligatoire)
Markdown propre. Le grill se termine toujours par ces deux blocs :
## 📋 À copier
Une entrée DEC-NNN prête à coller dans .planning/DECISIONS.md, au gabarit maison :
## DEC-NNN — <titre> — <AAAA-MM-JJ>
- **Contexte** : …
- **Décision** : …
- **Alternatives écartées** : …
- **Risk Guard** : LOW|MEDIUM|HIGH|CRITICAL
- **Routage (DEC-016)** : <dépôt cible>
- **Dry-run / rollback** : …
- **Reste à faire** : …
- **Statut** : Proposée | Acceptée | Acceptée — application différée
Suivi du diff STATE.md proposé (1 ligne) et, le cas échéant, de l'item TASKS.md.
goat next-id (ou lecture du dernier DEC) avant d'attribuer le numéro — jamais d'ID inventé.
## 📊 Notes de fiabilité
- Nœuds de l'arbre résolus vs laissés ouverts (et pourquoi).
- Hypothèses non vérifiées restantes.
- Sources citées si données externes (URL + date pub + date accès).
- Écart détecté avec un DEC existant, s'il y a lieu.
🧪 Auto-contrôle avant de rendre
tk-grill v0.1.0 — adaptation maison de grill-me, instrumentée pour la gouvernance DEC-NNN de TricorderKit.
