Prompt brief

Un modelo hace de más cuando el pedido deja huecos: no sabe dónde parar, así que rellena. Esta skill cierra los huecos antes de tocar código, con lo que el repo dice, no con lo que el modelo imagina. El brief es corto a propósito: cada línea le quita al modelo una decisión que no le toca.

El brief va en el idioma del último mensaje del usuario, no en el de esta skill. La etiqueta cambia con él: (supuesto) en español, (assumed) en inglés.

Dos entradas, dos salidas

Un pedido es ambiguo cuando falta una de estas tres cosas y el código no la resuelve: qué archivo o símbolo se toca, qué resultado observable se espera, o cuál de dos lecturas razonables es la pedida. Un pedido de 1–5 líneas con archivo y resultado claros no es ambiguo y no necesita brief.

Proceso

1. Lee lo mínimo para aterrizar el pedido: AGENTS.md y los archivos que el pedido nombra o que un grep del símbolo encuentra. No explores el repo.
2. Rellena cada hueco desde el repo. Archivo sin nombrar → grep del símbolo o del texto que el usuario citó. Convención sin decir → el archivo hermano más cercano. Comando de prueba → la línea Verify de AGENTS.md o los scripts del manifest. Cada campo cita de dónde salió (ruta, o el grep que lo encontró).
3. Marca lo que el repo no responde. Si una decisión no sale del pedido ni del código, va como (supuesto) con la opción que elegiste y por qué. Nunca inventes una ruta, una API, un flag ni un comportamiento que no leíste.
4. Pregunta solo lo que cambia el trabajo: máximo 2 preguntas, cada una con la opción que recomiendas. Si el supuesto no cambia el trabajo, no preguntes: un valor que se cambia en una línea (un umbral, un nombre, un texto) va como (supuesto) en el brief, nunca como "confírmame" o "avísame" al final.
5. Sal por la salida que corresponde (tabla de arriba). Con el "sí" del usuario, o al seguir por el router, ejecuta exactamente el brief bajo core y testing.

Plantilla

Objetivo: <un resultado observable, una frase>
Contexto: <por qué se pide, si cambia cómo se hace>
Archivos: <rutas exactas que se tocan; "nuevo:" para los que se crean>
Hacer:
  - <paso concreto>
Límites:
  - <convención del repo, API o patrón que se respeta>
Fuera de alcance: <lo cercano que NO se toca: refactors, renombres, otras pantallas>
Hecho cuando: <comando + exit esperado, o el recorrido de UI que lo demuestra>
Supuestos: <lista corta, o "ninguno">

Los rótulos se traducen al idioma del usuario. En inglés: Objective, Context, Files, Do, Limits, Out of scope, Done when, Assumptions.

Reglas de un buen brief

• Positivo y concreto: "usa el Result de platform/result.ts" en vez de "no inventes otro formato". Di qué hacer; las prohibiciones van solo en "Fuera de alcance".
• Un objetivo por brief. Si el pedido trae dos, propone dos briefs en orden.
• Archivos con ruta, no "el componente del sidebar". Si no se sabe cuál es, el primer paso de "Hacer" es encontrarlo y el brief lo dice.
• "Hecho cuando" es verificable: un comando que puede fallar, no "que funcione".
• El porqué va en Contexto cuando cambia la solución ("el cliente móvil depende de este campo" → no se renombra).
• Nada que el usuario no pidió. Si ves una mejora, va como una línea después del brief ("Aparte: …"), nunca dentro de "Hacer".
• Evidencia antes que memoria. Un dato del brief que no esté en el pedido o en un archivo leído en esta sesión es un supuesto, aunque suene obvio. Lo que recuerdes de otro proyecto o de una versión vieja de la librería no cuenta.

Por tipo de pedido

Ejemplo

Pedido: "arregla que el sidebar no se actualiza al renombrar un módulo".

Objetivo: al renombrar un módulo, el sidebar muestra el nombre nuevo sin recargar.
Contexto: hoy hay que presionar F5 (reportado por el usuario).
Archivos: features/modules/commands/rename-module.command.ts
Hacer:
  - Invalidar el tag del listado de módulos después del commit del rename.
Límites:
  - Mismo mecanismo de invalidación que usan los otros commands de modules.
Fuera de alcance: rediseño del sidebar, otros commands, estilos.
Hecho cuando: test del command verifica la invalidación; recorrido manual renombra y el sidebar cambia sin petición de documento.
Supuestos: el sidebar lee de list-modules.query.ts (supuesto, confirmado al leer).