grill-with-docs, de Matt Pocock, es una skill (instrucciones ejecutables para un agente de codificación) que convierte la fase de diseño en una rigurosa sesión de entrevista. Su principio: al diseñar una funcionalidad, el plan se apoya en hipótesis y dependencias de diseño; en lugar de precipitarse hacia la implementación, la skill "somete a la parrilla" el plan confrontándolo, hipótesis por hipótesis, con el vocabulario de negocio del proyecto y las decisiones ya tomadas. A medida que las decisiones se cristalizan, se registran en dos tipos de documentos: CONTEXT.md, un glosario de dominio (el vocabulario de negocio), y las ADR (Architecture Decision Records, en docs/adr/), para las decisiones de arquitectura significativas.
El mecanismo se apoya en cuatro principios. (1) Enfoque basado en entrevista: las preguntas se plantean secuencialmente, una a la vez, y el agente espera la respuesta antes de avanzar; si una pregunta puede resolverse explorando el código, el agente explora en lugar de preguntar. (2) Precisión del lenguaje — el núcleo de la skill: señalar de inmediato los conflictos de terminología con el glosario existente, proponer un término canónico cuando el usuario emplea una palabra vaga (por ejemplo, "cuenta"), y poner a prueba las relaciones de negocio con escenarios de casos límite concretos. (3) Basado en evidencia: contrastar el comportamiento anunciado con el código real y sacar a la luz las contradicciones. (4) Disciplina documental: CONTEXT.md se actualiza sobre la marcha (no en bloque al final); una ADR se crea solo si la decisión es difícil de revertir, sorprendente sin contexto, y procede de un verdadero trade-off.
En cuanto a las reglas estructurales: CONTEXT.md contiene únicamente el glosario de negocio (sin detalles de implementación, especificaciones ni borradores); un repositorio con múltiples dominios (bounded contexts en el sentido DDD) utiliza un CONTEXT-MAP.md que remite al CONTEXT.md de cada contexto; los archivos se crean bajo demanda (creación perezosa).
En resumen, se trata de una skill de diseño previo, inspirada en el Domain-Driven Design, que impone una conversación rigurosa antes de escribir código para ① depurar el vocabulario, ② verificar la coherencia con lo ya existente y ③ documentar las decisiones en el lugar adecuado y con el nivel de granularidad correcto — para evitar la deriva terminológica y las hipótesis no verificadas que resultan costosas más adelante.