snuffish/plan

Skill: /plan — Gestor de Planes de Implementación

Gestiona el plan de implementación activo (<prefijo>-implementation_plan-<sufijo>.md) para la sesión. Este skill es dueño del esqueleto del plan, sus valores de estado, su bloque de enlaces y su revisión (--review). Cualquier otro comando que escriba o lea un plan (/implement-feature, /problem, /refine, /pr-fix-pipeline, /proceed) usa las definiciones aquí.

---

Módulos

Las rutas son relativas a la carpeta real de este skill. Ejecute realpath en el directorio base del skill una vez (puede ser un enlace simbólico) y luego resuelva cada ruta desde allí. Si no se puede leer algún módulo, deténgase e informe la ruta. No continúe sin él.

Léalos antes del paso 1:

• ../_modules/core.md
• ../_modules/artifact-protocol.md: escribe <prefijo>-implementation_plan-<sufijo>.md en el directorio de artefactos (artifact-protocol).
• ../_modules/project-profile.md: solo perfil base (sin perfil de Comando), para la revisión (Caso D); lee Referencias por capa, Puntos de contacto con el contrato, Cadena de pares y un campo opcional Verificaciones de revisión del plan.

Referencias bajo demanda (references/):

• references/review.md — cinco pilares de revisión (Caso D paso 3) y plantilla de informe para --review (Caso D) y autorrevisión (Caso B paso 4).

---

1. El Contrato del Plan

Valores de Estado

La segunda línea del plan lleva **Estado:** <valor>, con uno de:

Valor	Significado	Establecido por
Draft	Escribiéndose; no listo para revisar	El escritor, durante el borrador
Awaiting User Review	Completo y esperando en la puerta	El escritor, al presentarlo
Approved	El usuario abrió la puerta; se está implementando	core › La puerta /proceed
Completed	Cada fase en alcance está hecha y verificada	core › La puerta /proceed

Una nota corta puede seguir al valor (Approved — fase 2 de 3 completada). Los lectores solo comparan el valor principal.

Esqueleto

<!-- artifact-owner: … -->                 <!-- artifact-protocol › Claim -->

# Plan de Implementación: <título>

**Estado:** Awaiting User Review
**Sufijo:** `<sufijo>`
**Entradas:** <enlaces a investigación / revisión / tickets, o "ninguna">
**Revisión:** <veredicto del Caso D después de plegar> · <n> hallazgos plegados <!-- Caso B paso 4 -->

## 1. Contexto y Objetivo

## 2. Decisiones <!-- tabla: decisión · por qué -->

## 3. Cambios Propuestos <!-- por fase o por repo: [NEW|MODIFY|DELETE] <ruta> — qué y por qué -->

## 4. Plan de Verificación <!-- comandos exactos, más pasos manuales -->

## 5. Riesgos <!-- tabla: riesgo · mitigación -->

## 6. Lista de Tareas <!-- la lista de verificación en vivo: [ ] / [/] / [x] -->

## 7. Preguntas Abiertas <!-- preguntas no resueltas; siempre al final, si las hay; cada una con una recomendación -->

Un comando puede agregar las secciones que necesite (/implement-feature añade Revisión de Usuario Requerida, Pase de Puntos Ciegos y Orden entre repos). Mantiene estas siete, en este orden, para que /plan, /plan --review y /proceed puedan encontrarlas. Preguntas Abiertas (preguntas no resueltas) es siempre la última sección; cualquier sección añadida va antes de ella.

Estilo

Se aplica la regla del usuario (~/.claude/CLAUDE.md › Plan Mode): extremadamente conciso, se sacrifica la gramática; terminar con Pasos, luego Preguntas no resueltas (cada una con una recomendación, omitidas si no las hay).

Cada escritor de plan lo aplica al archivo completo y a la respuesta de chat que presenta el plan:

• Fragmentos, no prosa: sin párrafos, sin explicaciones con oraciones completas.
• Una idea por viñeta; dividir una más larga en subviñetas.
• Decisiones y Riesgos como tablas.
• Cada pregunta abierta lleva Rec: con la respuesta recomendada.
• Nada después de Preguntas Abiertas. Si no hay preguntas no resueltas, indicar "Ninguna" (u omitir).

Bloque de Enlaces

Cada respuesta de chat que presenta un plan comienza con el Bloque de enlaces de chat de artifact-protocol (números de línea reales de grep -n '^#\{1,3\} ' <archivo> después de escribir) que enlaza a Contexto y Objetivo, Cambios Propuestos, Plan de Verificación y Preguntas Abiertas, seguido de **Estado:** <valor>. Un comando puede agregar un resumen de una línea después de cada enlace de sección (/plan --review lo hace).

---

2. Comportamientos Principales

Elija el caso según los argumentos, la primera coincidencia gana:

Argumentos	Caso
Contienen --review	D: revisar un plan
Comienzan con preview	C: previsualizar
Ninguno	A: comando simple
Cualquier otra cosa	B: redactar o actualizar

Caso A: Comando Simple (/plan sin argumentos ni mensaje)

1. Localizar el plan: buscar <prefijo>-implementation_plan-*.md en el directorio de artefactos (artifact-protocol) y seleccionar la familia según artifact-protocol › Claim › Readers & family selection (indique al usuario que puede omitir el aviso la próxima vez con /plan <sufijo>). Si no existe ninguno, dígalo y ofrezca crear uno a partir del siguiente mensaje del usuario.
2. Renderizar el bloque de enlaces (§1 Bloque de enlaces) para el plan elegido, con su Estado actual. No edite nada ni ejecute comandos en segundo plano.

Caso B: Comando con Instrucciones (/plan <instrucciones>)

1. Resolver el sufijo contextual según artifact-protocol › regla 2.
2. Planificar, sin cambiar código:
   • Verificar primero si existe una investigación. Si <prefijo>-investigation-<sufijo>.md existe en el directorio de artefactos (artifact-protocol) y cubre este tema, construir sobre ella: su Semilla del Plan, Opciones y Compensaciones y Registro de Confianza. No repetir la investigación que ya documenta; sí resolver cualquier ❓ Desconocido del que dependa el plan.
   • De lo contrario, investigar el código relevante en modo solo lectura. Si el tema es grande o las incógnitas son sustanciales, ejecute primero /investigate.
   • Diseñar según las propias convenciones del proyecto: sus libros de reglas del espacio de trabajo, Referencias y Perfil del proyecto (core › Precedencia).
3. Escribir el plan en el §1 Esqueleto, en el directorio de artefactos (artifact-protocol):
   • Plan nuevo: redactarlo en una ruta privada de la sesión, luego publicarlo con Claim (artifact-protocol › regla 4). Si el nombre base ya está ocupado, Claim escribe …-2.md; use la ruta que imprimió y dígalo en el chat.
   • Plan existente: actualizarlo solo si su marcador de propietario nombra a esta sesión, o si el usuario nombró ese archivo y pidió que se actualice (artifact-protocol › regla 3). De lo contrario, escribir una nueva revisión mediante Claim y enlazar la que reemplaza en Entradas.
   • Establecer Estado en Awaiting User Review cuando esté completo. En Antigravity, al escribir una copia de artefacto reflejada dentro de <appDataDir>/brain/<conversation-id>/, establecer UserFacing = true y RequestFeedback = true en ArtifactMetadata (omitir ArtifactMetadata en el archivo del directorio de artefactos).
4. Autorrevisión antes de presentar: leer references/review.md y ejecutar los pasos 2–3 del Caso D en el plan recién escrito, en el contexto principal. Usar sus pilares y severidades. No imprimir su informe ni su puerta: esto es parte del borrador, y el usuario revisa el plan plegado.

   • Plegar cada hallazgo en el plan antes de presentar:

     Hallazgo	Va a
     🔴 / 🟡, verificado (ruta:línea reabierto)	Cambios Propuestos, Lista de Tareas y una verificación en el Plan de Verificación que falla sin la corrección
     🔴 / 🟡 que necesita una decisión del usuario	Preguntas Abiertas, con Rec:
     🟢	Aplicar si es de una línea; si no, descartar
     Hallazgo rechazado	Riesgos, una fila con el motivo

   • Releer el plan una vez en busca de cualquier cosa que contradiga una corrección (un paso anterior, una prueba, una fila de decisión) y corregirlo.

   • Ejecutar la revisión una vez. Rellenar la línea de cabecera Revisión: con el veredicto que obtendría el plan plegado.

   • Ejecutarlo en cada plan nuevo y en cada actualización que cambie Cambios Propuestos o Plan de Verificación. Omitirlo para una actualización que solo marque la lista de tareas o cambie Estado.

5. Presentar el plan: el bloque de enlaces (§1 Bloque de enlaces), el veredicto de la revisión y los hallazgos que cambiaron el diseño (una viñeta cada uno), las decisiones clave como viñetas de fragmentos, luego las preguntas abiertas al final, cada una con su Rec: (§1 Estilo también se aplica a este texto de chat: sin párrafos, sin oraciones completas). Esperar a que el usuario abra la puerta (core › La puerta /proceed) antes de cualquier cambio de código.

Caso C: Comando de Previsualización (/plan preview [objetivo])

Muestra un plan existente en el panel de previsualización de planificación del host (usando ExitPlanMode cuando esté disponible), para que el usuario pueda leer, comentar y aprobar el plan de forma interactiva.

1. Resolver el plan: Usar el argumento (ruta o sufijo), el archivo de plan activo de la sesión, o la última familia de plan en el directorio de artefactos (Caso A).
2. Verificación de capacidad del host: Si el host carece de ExitPlanMode (como Antigravity IDE), mostrar el bloque de enlaces del plan (Caso A) y explicar que el host renderiza los planes directamente mediante enlaces Markdown.
3. Entrar en modo plan y copiar: Llamar a EnterPlanMode, leer la ruta del archivo de plan del host desde el mensaje del sistema y copiar el plan fuente en ella (omitiendo el comentario inicial <!-- artifact-owner: … -->).
4. Abrir previsualización: Llamar a ExitPlanMode.
5. Manejar la decisión:
   • Aprobar: El usuario autorizó la implementación (core › La puerta /proceed). Comenzar la ejecución.
   • Seguir planificando / Comentarios: Permanecer en modo plan, pasar los comentarios al Caso B para actualizar el plan y reabrir la previsualización.
   • Cerrado / Error: Informar el estado y proporcionar el enlace al archivo.

Caso D: Comando de Revisión (/plan --review [objetivo])

Auditoría estricta y de solo lectura de un plan de implementación, propuesta arquitectónica o diseño de cambio, antes de escribir cualquier código. Solo lectura hasta /proceed (core › La puerta /proceed):

• Nunca editar archivos, ejecutar comandos modificadores (migraciones, commits, scaffolding) ni comenzar a implementar, incluso si el plan es impecable.
• Cada respuesta bajo --review, incluidas las de seguimiento, comienza con el bloque de enlaces: el usuario a menudo cierra la pestaña del plan y la vuelve a abrir desde el chat.

Herramienta incorrecta:

Situación	Usar en su lugar
Un diff de código, rama o PR en lugar de un plan	/code-review
Comentarios y votos de revisores en un PR	/pr-feedback-review
Investigación antes de que exista un plan	/investigate
Suposiciones ocultas y modos de fallo de un diseño	/what-am-I-missing

Leer references/review.md y ejecutar los pasos 1–4 del Caso D (paso 1: localizar el plan; paso 2: leer las reglas del proyecto; paso 3 del Caso D: evaluar contra los cinco pilares + perfil Verificaciones de revisión del plan; paso 4: renderizar bloque de enlaces e informe de revisión), luego esperar en core › La puerta /proceed.