grill — stress-tester une conception en interrogeant son auteur
Entrée : un plan, une spécification ou une idée de conception (dans un fichier ou uniquement en chat). Sortie : chaque décision ouverte résolue avec l'humain une branche à la fois, chaque résolution écrite dans son emplacement canonique, et chaque contradiction entre les réponses de l'utilisateur et la base de code surfacée en cours de route.
Supervisé uniquement. Cette skill existe pour interroger un humain ; il n'y a pas de variante autonome. À l'intérieur d'une boucle automatisée (conductor, exécutions headless/outer-loop), NE l'invoquez PAS — le mode autonome de spec-writing (résolutions basées sur des recommandations enregistrées comme **Autonome :**, territoire Ask-First → BLOQUÉ) en est le substitut.
Annoncez au démarrage : « Utilisation de la skill grill — stress-testing {target}. »
Étape 1 : Identifier la cible et sa destination d'écriture
| Grilling | Les questions proviennent de | Les résolutions sont écrites dans |
|---|---|---|
Une spec (.ai/specs/…) |
sa section Open Questions, plus tout ce qui est flou dans Design Decisions | inline dans la spec : - [x] {Question} — **Réponse :** {décision et rationale}, plus une entrée de changelog une fois terminée |
| Une spec en cours de conception (étape 5 de spec-writing — pas encore de fichier) | la liste de questions assemblée à l'étape 4 de spec-writing | apportée à la section Open Questions de la spec (pré-cochée, avec réponses) quand la spec est écrite à l'étape 6 |
Un plan (.ai/plans/…) |
tâches ambiguës ou risquées, critères d'acceptation manquants | la tâche affectée dans le fichier du plan |
| Une idée en chat (pas d'artifact) | tout l'arbre de décision de l'idée | .ai/runs/{YYYY-MM-DD}-grill-{slug}.md — le créer quand la première décision arrive |
Si la cible n'a pas d'artifact et le grill révèle qu'elle mérite une spec (nouveau module, changement de modèle de données, ou 3+ fichiers — le tableau /spec-writing), dites-le et proposez /spec-writing. Continuez le grilling sans artifact uniquement si l'utilisateur décline.
Étape 2 : Choisir la profondeur selon le rayon d'impact
| La cible implique | Profondeur |
|---|---|
| Nouveau module, changement de modèle de données ou comportement cross-module | Full grill — strictement une question par message |
| Tout ce qui est plus petit | Light grill — les questions étroitement liées peuvent être regroupées, max 2–3 par message |
La profondeur change le regroupement uniquement. Chaque règle de l'étape 3 s'applique aux deux profondeurs, et ne présentez jamais la liste de questions entière à la fois en attendant des réponses par lot.
Étape 3 : Entretien
Parcourez l'arbre de décision branche par branche, en résolvant les dépendances entre les décisions une par une. Attendez la réponse de l'utilisateur avant de continuer. Pour chaque question :
- Ordonnez selon la dépendance : réglez d'abord les décisions dont d'autres questions dépendent.
- Joignez votre réponse recommandée avec une rationale d'une ligne.
- Si la question peut être résolue en explorant la base de code ou un fichier de recherche existant, répondez de cette façon plutôt que de demander.
- Validez chaque réponse par rapport au code. Surfacez les contradictions immédiatement, avec références de fichiers : « vous avez dit X, mais
{file}fait Y — lequel est correct ? » - Stress-testez les réponses floues avec un scénario concret avant de les accepter (« un PO a 3 lignes et l'une est déjà reçue — que se passe-t-il lors de l'annulation ? »).
- Affinez les termes flous. Quand l'utilisateur utilise un mot vague ou surchargé, proposez le terme canonique précis. Consultez
packages/glossary(l'objettermsdans@carbon/glossary) pour une définition existante et contestez les conflits : « la glossaire définit {term} comme {definition} ; vous semblez vouloir dire {other} — lequel est-ce ? »
Étape 4 : Écrire en retour à chaque décision qui arrive
Ne regroupez pas les retours d'écriture à la fin de la session — enregistrez chaque résolution dans la destination de l'étape 1 dans le même tour où elle est décidée. Deux destinations supplémentaires s'appliquent indépendamment de la cible :
- Une décision qui établit une convention durable au-delà de cette feature → mettez à jour le fichier
.ai/rules/*.mdcorrespondant dans le même tour. - Un terme de domaine canonique vraiment nouveau → proposez une entrée
@carbon/glossary, uniquement quand les trois conditions tiennent : le terme est orienté utilisateur (UI ou docs), le grill a révélé une véritable ambiguïté, et l'utilisateur a confirmé la définition. Suivezpackages/glossary/AGENTS.md(sa règle « Ask First » est satisfaite par la confirmation de l'utilisateur dans l'entretien).
Terminé quand
- [ ] Aucune branche non résolue : chaque question répondue par l'utilisateur, la base de code, ou une décision explicitement documentée « hors de portée »
- [ ] Chaque résolution enregistrée dans la destination de l'étape 1 — aucune n'existe uniquement en chat
- [ ] Les conventions durables reflétées dans
.ai/rules/; les offres glossaire faites où le test en trois parties a réussi
Anti-patterns
- Déverser la liste de questions complète en un message et accepter les réponses par lot
- Accepter une réponse sans la vérifier par rapport au code
- Résoudre vous-même une question pour continuer — seul l'utilisateur, la base de code, ou une décision documentée hors de portée résout une question
- Enregistrer les décisions uniquement en chat (« je les écrirai à la fin »)
Signaux d'alerte — penser l'un de ceux-ci signifie que le grill est contourné ; ARRÊTEZ :
- « l'utilisateur veut probablement dire X, je vais le supposer » (cette supposition EST la question)
- « nous pouvons régler cela pendant l'implémentation »
- « je regrouplerai les retours d'écriture quand la session se termine »