xallindrome-labs/claude-code-ops

/runway

Objetivo: cada pregunta se hace ahora, para que no sea necesario preguntar nada en el turno 40. Después, el usuario aprueba un plan y se retira; solo se le notifica al teléfono en los puntos de parada.

Reglas básicas (el usuario puede tener las suyas en CLAUDE.md; las suyas prevalecen):

• El trabajo local y reversible (ediciones, compilaciones, pruebas, comandos locales, commits en una rama o worktree) se ejecuta sin preguntar.
• Detenerse siempre para: push o deploy, enviar cualquier mensaje, enviar cualquier solicitud, gastar dinero, eliminar datos, publicar algo público.
• Usar modelos de subagente más baratos para trabajo voluminoso (búsquedas, ejecuciones de pruebas, revisión de logs); el modelo superior solo para diseño y depuración compleja.

0. Verificación previa (silenciosa, sin preguntas)

• Encontrar la raíz del repositorio y su estado: git status, rama actual, un SPEC.md existente, scripts de prueba y compilación (package.json, Makefile, etc.). Encontrar hechos es tu trabajo, no del usuario.
• Verificar si las aprobaciones por teléfono están activas. Lo están si ~/.claude/settings.json tiene un hook PermissionRequest que ejecuta phone-approve.js, o si el hook de este plugin está habilitado, y existe ~/.claude/phone-approve.json. Si no es así, informar al usuario una vez (configuración: ejecutar node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init, luego suscribir la app ntfy al tema de solicitud en ese archivo) y continuar; los puntos de parada recurren al diálogo de escritorio.
• Verificar que los comandos de punto de parada están forzados a preguntar, porque el modo automático podría aprobarlos sin notificar. Buscar en la configuración de usuario, proyecto y local las reglas permissions.ask (o deny) que cubran git push, los comandos de deploy de este repositorio (vercel, aws s3 sync, cdk deploy, npm publish, gh release, gh pr merge) y los comandos de eliminación (rm -r, git clean, git branch -D). Si faltan reglas, proponer las específicas, mostrar el diff y agregarlas solo si el usuario dice que sí (el examples/permissions-ask.json del plugin es un punto de partida). Nunca agregar reglas allow para herramientas de enviar, publicar o desplegar, y nunca Bash(*).

1. Entrevista hasta que la especificación esté completa

Si hay una skill grilling o grill-me instalada, llamarla y ejecutarla sobre esta funcionalidad; sus reglas se aplican en su totalidad. Si no, ejecutar la entrevista tú mismo así: preguntar en rondas; cada ronda contiene todas las preguntas cuyos prerrequisitos ya están resueltos, cada una numerada, cada una con tu respuesta recomendada redactada de modo que "sí" la acepte. Esperar las respuestas, recalcular lo que ahora se puede preguntar y repetir. Buscar hechos del entorno tú mismo (usar un subagente para búsquedas voluminosas) y nunca preguntar al usuario algo que puedas averiguar. Las decisiones son del usuario.

Si el usuario ya realizó una sesión de grilling sobre esta funcionalidad antes en la conversación y confirmó entendimiento compartido, no repetirla: reutilizar las respuestas y preguntar solo sobre los elementos de la lista de verificación que quedaron abiertos.

Continuar hasta que no quede nada abierto en todos los siguientes:

1. Objetivo: una o dos frases, el resultado visible para el usuario.
2. Alcance: qué cambiará (áreas, archivos, superficies).
3. Fuera de alcance: qué no debe tocarse.
4. Criterios de aceptación: una lista de verificación donde cada elemento pueda demostrarse verdadero mediante la salida de un comando.
5. Comando de verificación: exactamente un comando cuya salida 0 significa listo (por ejemplo npm run lint && npm test && npm run build). Si no existe, la especificación incluye escribirlo como la primera tarea.
6. Puntos de parada: cuáles de push / deploy / send / submit / spend / delete / publish alcanzará esta funcionalidad, y qué espera el usuario en cada uno (por ejemplo "hacer push de la rama, abrir un PR, no fusionar").
7. Decisiones que tomarías de otro modo a mitad de tarea: librerías, nombres, formas de datos, copy, comportamiento en casos límite. Preguntar ahora, con una recomendación.
8. Límite de turnos (60 por defecto) y cualquier preocupación de presupuesto.

No avanzar hasta que el usuario confirme entendimiento compartido.

2. Escribir SPEC.md y hacer commit localmente

Escribir SPEC.md en la raíz del repositorio:

# <nombre de la funcionalidad>
## Objetivo
## Alcance
## Fuera de alcance
## Criterios de aceptación
- [ ] ...
## Comando de verificación
`<un comando>`
## Puntos de parada
| Acción | Manejo esperado |
## Decisiones ya tomadas
## Límite de turnos
60

Crear una rama (git switch -c runway/<slug>), o usar un worktree cuando otras sesiones estén editando la misma carpeta, luego hacer commit solo de SPEC.md. Esto es local y reversible; no preguntar. Nunca hacer push.

3. Una aprobación de plan

Entrar en modo plan y presentar un único plan: pasos ordenados, qué pasos van a subagentes (y en qué modelo), el comando de verificación y los puntos de parada con su manejo esperado. Esta es la única aprobación antes de la ejecución. Usar ExitPlanMode y pedir al usuario que elija "Sí, y usar modo automático". (El hook de teléfono omite deliberadamente la aprobación del plan, por lo que el usuario hace esto en la computadora.)

Si el modo automático no está activo después de la aprobación, decirlo y pedir al usuario que lo active. No ejecutar el bucle en modo manual.

4. Ejecutar bajo /goal con un límite de turnos

Los comandos de barra incorporados no pueden ser invocados por el modelo, así que finalizar el paso anterior dando al usuario una línea para pegar (completar el comando real y el límite):

/goal <comando de verificación> sale 0, cada criterio de aceptación en SPEC.md está marcado con evidencia en la transcripción, y nada en la lista fuera de alcance de SPEC.md fue tocado, o detenerse después de 60 turnos

Si la sesión ya está ejecutando un objetivo, /goal lo reemplaza. El evaluador solo ve la transcripción, así que mientras se trabaja: ejecutar el comando de verificación a menudo, imprimir su resultado y marcar los criterios de SPEC.md con evidencia. Informar el progreso contra el límite de turnos en cada turno.

Mientras se ejecuta:

• No hacer preguntas. Si surge algo no especificado, elegir la opción más cercana a la especificación, registrarla en "Decisiones ya tomadas" y continuar. Detenerse para hacer una pregunta solo cuando proceder implicaría alcanzar un punto de parada o contradecir la especificación.
• Hacer commits de trabajo en commits pequeños en la rama runway. Nunca hacer push sin una aprobación de punto de parada.
• En un punto de parada, hacer la llamada normalmente; el aviso de permiso es lo que notifica al teléfono. Si es denegado, no intentarlo de otra manera: registrarlo, terminar lo que no lo necesita e informar.
• Si 3 turnos consecutivos no progresan, detenerse e informar qué te bloqueó.

5. Finalizar

Cuando la verificación pase (o se alcance el límite), informar en este orden:

1. Resultado: listo / parcialmente listo / bloqueado, más la rama y cualquier enlace al PR.
2. Estadísticas del diff (git diff --stat <base>...HEAD).
3. Verificado: criterios demostrados, con el comando y el resultado.
4. No verificado: criterios no demostrados o solo parcialmente; cualquier cosa omitida o denegada en un punto de parada.
5. Subagentes utilizados, en qué modelo y dónde un modelo más pequeño rindió peor.
6. Turnos y costo aproximado utilizados contra el límite.