/grill-me: el comando que obliga a Claude a preguntar antes de escribir código

Le pides algo a Claude, no pregunta nada, se lanza, y te devuelve trescientas líneas que no eran lo que querías. No es que no sepa: es que ha rellenado los huecos por ti. Tú tenías veinte decisiones en la cabeza y él tuvo que adivinarlas todas.

/grill-me invierte eso. Antes de tocar un fichero, te interroga.

Qué es exactamente

No es un comando suelto: es una skill, y son tres carpetas. grill-me es solo un puntero a grilling, que es donde vive la lógica. Lleva disable-model-invocation: true, así que Claude no puede lanzarla por su cuenta: solo se activa si tú escribes /grill-me.

Eso está bien pensado. Una entrevista de veinte preguntas que arranca sola sería insoportable.

Las cuatro cosas que lo hacen distinto

1. Es un árbol, no una lista

Mapea lo que quieres hacer como un árbol de decisiones: cada decisión abre las que cuelgan de ella. No es un cuestionario fijo, es una estructura que crece con tus respuestas.

2. Pregunta por rondas

En cada ronda solo lanza la frontera: las preguntas cuyos prerrequisitos ya están resueltos. Lo que depende de una respuesta que aún no tiene se guarda para la ronda siguiente.

Por eso no te caen cuarenta preguntas de golpe. Te caen dos, contestas, y aparecen cuatro que antes no existían porque no tenían sentido todavía.

3. Cada pregunta viene con su respuesta recomendada

Este es el detalle que lo hace usable, y el que casi nadie espera. El formato es literalmente este:

❓ **Q1** - **<título>**: <la pregunta, con sus opciones>

➡️ <la respuesta que recomienda>

Puedes decir "sí a todo" y cambiar solo las dos que no te encajan. No te interroga: te propone y tú corriges.

4. Los hechos los busca él

Cuando una pregunta necesita saber algo del proyecto —qué versión usas, si ya existe ese módulo, cómo está montado el enrutado— no te lo pregunta: lanza un subagente y lo mira. Solo te consulta lo que de verdad es una elección tuya.

Y no bloquea mientras busca: las preguntas que no dependen de ese dato te las hace igual.

Cuándo termina

Cuando la frontera se vacía: ni una rama del árbol sin visitar, nada asumido en silencio. Y no empieza a implementar hasta que tú confirmes que estáis de acuerdo.

Los tres ficheros

Van en ~/.claude/skills/ (para todos tus proyectos) o en .claude/skills/ dentro de uno solo. Cada skill es una carpeta con su SKILL.md dentro.

grill-me/SKILL.md

---
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
---

Call the Skill tool with "grilling".

grill-with-docs/SKILL.md

La segunda versión. Hace lo mismo, pero además va generando los ADRs y el glosario del proyecto mientras te entrevista. Para cuando la decisión hay que dejarla escrita.

---
name: grill-with-docs
description: A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.
disable-model-invocation: true
---

Call the Skill tool twice, for "grilling" and "domain-modeling".

grilling/SKILL.md

La tercera es el motor, y la única que Claude puede invocar solo cuando detecta que quieres poner a prueba una idea.

---
name: grilling
description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
---

Interview the user relentlessly until you reach a shared understanding. Map this
as a **design tree**: every decision branches into the decisions that hang off it.

Work the tree in **rounds**. The **frontier** is every decision whose
prerequisites are already settled: the questions you can ask _now_ without
guessing at answers you haven't heard yet. Ask the whole frontier in one round:
number each question and give your recommended answer. Then wait for the user's
answers before the next round.

Format a round like so:

❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs,
including multiple choices>

➡️ <your recommended answer>

Each round the user answers reshapes the tree: settled decisions push the
frontier outward and unblock questions that depended on them. Recompute the
frontier and ask the next round. A question whose answer depends on another
question still open in this round belongs to a _later_ round, not this one.

Finding _facts_ is your job, never the user's. When a frontier question needs a
fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to
find it; don't ask the user for anything you could look up yourself. Don't block
on it: a running exploration is an unsettled prerequisite, so only the questions
downstream of it wait for the sub-agent to report; ask the rest of the frontier
now. The _decisions_ are the user's: put each to them and wait.

The session is done when the frontier is empty: every branch of the design tree
visited, nothing left silently assumed. Do not act on it until the user confirms
you have reached a shared understanding.

Cuándo usarlo y cuándo no

Sí: features nuevas, migraciones, cualquier cosa donde haya más de tres decisiones de arquitectura. Cuanto más grande el encargo, más rentable son los dos minutos de preguntas.

No: arreglar un bug concreto, cambiar un texto, tareas de un solo paso. Ahí la entrevista es pura fricción, y por eso está bien que no se active sola.

El detalle que más cambia el resultado

Contesta las preguntas en corto. La tentación es escribir un párrafo por respuesta, y no hace falta: "opción 2", "la 1 pero sin el carrito", "sí a todo menos la 3". El árbol avanza igual y terminas en dos minutos en lugar de en diez.

Y cuando algo no te encaje, dilo entonces, no después. Toda la gracia del comando es que discutir una decisión antes de escribir cuesta una frase; discutirla después cuesta una hora reescribiendo.