Decisiones que cada plan volvería a preguntar
Cada sesión de planeación choca con las mismas preguntas: para quién es este producto, qué tanto se tienen que parecer dos pantallas, qué nunca va a hacer. No son huecos de una tarea. Son decisiones que nadie dejó por escrito, así que cada tarea las vuelve a pagar.
/vision las deja por escrito una vez, en el vision.md de tu proyecto. /plan-prompt lo lee antes de preguntarte nada, así que una pregunta que la visión ya responde deja de hacerse.
Corre pocas veces: una para crear el documento, y otra solo cuando quieres completar o revisar una parte. No es un paso de ninguna tarea.
Cuándo la pide la planeación
Cuando planeas un cambio que decide algo y tu proyecto todavía no tiene visión, /plan-prompt se detiene y te dice que corras /vision primero y vuelvas. No la corre por ti.
Si dijiste que la tarea es urgente, la planeación sigue sin ella y, cuando te entrega el plan, te dice que se hizo sin visión y que /vision igual vale la pena. Un cambio que no decide nada se construye directo y nunca se detiene por una visión. La diferencia entre los dos está en Qué ruta toma tu cambio.
Las siete cosas que pregunta
| Categoría | Qué deja resuelto |
|---|---|
| Público y objetivo | Quién usa el producto, qué intenta lograr y para qué sirve. |
| Principios de consistencia | Qué tanto se tienen que parecer en aspecto y comportamiento dos pantallas que hacen cosas parecidas, y dónde se permite variar. |
| Tono y comunicación | Cómo habla el producto: a quién, con qué formalidad y qué nunca dice. |
| Reglas de negocio transversales | Las reglas que valen en todas partes: lo que siempre es cierto sobre dinero, permisos, fechas y propiedad. |
| Lo innegociable del producto | Lo que el producto no va a hacer, lo pida quien lo pida. |
| Nombres del dominio | Cómo se llaman las cosas aquí, y cómo nunca se llaman. |
| Prioridades del producto | Qué se sacrifica primero cuando algo tiene que ceder: rapidez, completitud, simplicidad, costo. |
Te propone, tú confirmas
No se te pide escribir nada de esto desde una hoja en blanco. Antes de preguntar, /vision lee lo que tu proyecto ya dice de sí mismo: su README, lo que le muestra al mundo — una landing, los textos de sus pantallas de entrada —, su documentación de desarrollo y las instrucciones que da a sus asistentes, y al final los nombres que usa el código. Redacta una respuesta para cada categoría de la que hablan esas fuentes, y cada propuesta nombra de dónde salió, para que la corrijas con una palabra.
Una categoría que nada del proyecto responde llega como una pregunta simple, y se dice que lo es. Todas las categorías pendientes llegan en un solo mensaje, no una por una.
Una propuesta no es una respuesta. Lo que confirmas se escribe como respuesta, lo que corriges se escribe corregido y lo que dejas sin contestar se escribe como pendiente. El silencio nunca convierte una propuesta en una decisión, porque la siguiente sesión de planeación confiaría en ella como si lo fuera.
Dónde vive
vision.md es un documento de tu proyecto en el toolkit, no un archivo de tu repositorio. Lo encuentras en la raíz de tu proyecto en la sección Proyectos; no tiene rama ni estado. Mira Tus proyectos y sus documentos. Cuando el toolkit no está conectado, /vision se detiene y lo dice en lugar de escribir la visión en otro lado.
Correrlo otra vez
Una corrida posterior lee primero el documento que ya existe. Cada categoría ya respondida se queda como está: /vision llena lo que sigue pendiente y revisa solo lo que le pidas revisar, propuesto de la misma forma a partir de lo que el proyecto dice hoy.
Lo que la primera corrida corrige además
La corrida que crea vision.md hace una cosa más, una vez por proyecto. La planeación lee tu documentación de desarrollo antes que el código, y eso solo funciona si esa documentación es cierta.
- Documentación de desarrollo. El agente
analystlee la documentación de la carpeta de documentación de tu proyecto contra el código y reporta lo que ya no es cierto. Ves la lista antes de que cambie nada, y solo se corrige lo que confirmas. Lo que nadie documentó no se escribe aquí: eso es trabajo de/document. - Estados de los análisis. Cada análisis de la carpeta
analysis/de tu proyecto se lee contra el código con una sola pregunta: ¿lo que describe está construido? Uno construido que no está marcado así se propone para Implementado. Los pausados y descartados se quedan como los dejó una persona, y uno construido a medias se deja como está y se reporta. Todo esto entra en la misma confirmación.
La visión y cualquier estado que mueva viven en el toolkit y nunca se commitean. Cuando corrigió documentación de desarrollo, que sí vive en tu repositorio, hace un commit solo con esos archivos. A un proyecto sin nada que corregir se le dice así.
Decisiones que la planeación le propone
La planeación está atenta a lo que te pregunta. Cuando tres planes anteriores resolvieron la misma pregunta de la misma forma, y la respuesta cabe en una de las siete categorías, te pregunta si esa respuesta va en la visión. Si dices que sí, te dice la categoría y la respuesta que hay que anotar, y tú corres /vision para escribirla. A partir de ahí esa pregunta ya no se hace.
Sigue por aquí
- Planear antes de construir — el paso de planeación que lee la visión.
- Qué hace cada comando —
/visionjunto a los demás comandos. - Tus proyectos y sus documentos — dónde está
vision.md.