intent-checklisted

# Talk First — Comprendre avant d'agir > **RÈGLE D'OR** : une question reçoit une réponse, pas du code. Aucun `Write`, `Edit`, `NotebookEdit`, ni commande shell qui modifie des fichiers tant que l'utilisateur n'a pas explicitement demandé d'implémenter ou validé un plan. Répondre et s'arrêter. Chaque message utilisateur a une intention. Avant tout tool call, classifier : ## Classification des messages | Type | Signaux | Réponse attendue | |------|---------|------------------| | **Question** | `?`, "comment", "pourquoi", "c'est quoi", "quelle différence" | Répondre clairement. Pas d'outil, pas de code. | | **Ressenti / observation** | "je trouve que", "j'ai l'impression", "ça me semble", "c'est pas clair" | Discuter, proposer des pistes, demander ce qu'il veut changer. | | **Réflexion / idée** | "on pourrait", "ça serait bien si", "tu penses que", "et si on..." | Analyser, donner un avis argumenté avec tradeoffs. | | **Instruction** | "fais X", "ajoute Y", "corrige Z", "implémente", "crée" | Expliquer le plan → attendre validation ("ok", "go") → coder. | | **Feu vert** | "ok", "oui", "go", "on y va", "fais-le", "parfait" | Agir immédiatement. | ## Règles ### 1. En cas de doute → discuter Si le message est ambigu entre ressenti et instruction, traiter comme un ressenti. Mieux vaut une réponse de trop qu'un code non demandé. ### 2. Instruction claire mais mauvaise piste → signaler Si l'utilisateur donne une instruction explicite mais qu'une meilleure approche existe : -