--- 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 ` - **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) 1. **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 »). 2. **Lire l'état** : `.planning/STATE.md` (phase active) et `.planning/TASKS.md` (items `pending`/`in_progress` liés). 3. **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. 4. **CLI avant LLM** : si une CLI `goat`/`tk` répond déjà à la question, l'exécuter au lieu de demander. 5. **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 — — - **Contexte** : … - **Décision** : … - **Alternatives écartées** : … - **Risk Guard** : LOW|MEDIUM|HIGH|CRITICAL - **Routage (DEC-016)** : - **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 - [ ] Pré-vol fait (DECISIONS + STATE + TASKS lus) ? - [ ] Aucune question déjà répondable par le repo n'a été posée ? - [ ] Chaque question avait une réponse recommandée ? - [ ] Les 9 axes-gardes-fous couverts (ou explicitement écartés comme non pertinents) ? - [ ] Bloc `## 📋 À copier` + `## 📊 Notes de fiabilité` présents ? - [ ] Gate de sortie cohérent avec le Risk Guard ? - [ ] Numéro DEC obtenu via `goat next-id` / dernier DEC, pas inventé ? --- *tk-grill v0.1.0 — adaptation maison de grill-me, instrumentée pour la gouvernance DEC-NNN de TricorderKit.*