pa-stack

Activame cuando el creador diga 'sé cuidadoso', 'careful', 'no rompas nada', 'modo seguro', o cuando esté trabajando en producción. Advierto antes de ejecutar comandos destructivos: rm -rf, DROP TABLE, force push, git reset --hard, truncate.

Úsame cuando hay un bug específico que no se entiende, un error que se repite, o algo que 'debería funcionar pero no funciona'. También cuando el creador diga 'no entiendo por qué falla esto', 'ayúdame a debuggear', 'encuentra el bug'. Ley de hierro: investigo antes de tocar código.

Úsame después de lanzar para actualizar la documentación del proyecto. Cuando el creador diga 'actualiza los docs', 'el README está desactualizado', o después de un /ship exitoso. Leo qué cambió en el PR y actualizo README, CHANGELOG, y cualquier doc que haya quedado obsoleto.

Úsame cuando el creador quiera restringir edits a un solo directorio. 'Congela src/', 'solo toca el frontend', 'no toques la DB'. Útil cuando se debuggea algo específico y no se quiere que el agente toque otras partes del código por accidente.

Úsame cuando el plan técnico involucra cambios de UI y el creador quiere revisar el diseño antes de implementar. También cuando digan 'revisa el diseño', 'cómo se ve esto', 'audita la UI', 'detecta AI slop'. Solo reporto — nunca toco código.

Úsame cuando el design doc esté aprobado y el creador quiera planear la implementación técnica. También cuando digan 'cómo lo implementamos', 'crea el plan técnico', 'arquitectura'. Leo el design doc de /think y produzco un plan técnico con diagramas, edge cases y test matrix que /review y /qa van a usar.

Úsame para testear la app en un browser real. Cuando el creador diga 'testea la app', 'corre QA', 'verifica que funciona', 'abre el browser', o cuando /review haya terminado y la fase sea 'testeando'. Uso Playwright para navegar la app, hacer clicks reales, y encontrar bugs que el código no puede ver.

Úsame al final de la semana o del sprint para ver qué se logró. Cuando el creador diga 'retro', 'qué hice esta semana', 'resumen del sprint', o 'qué tan bien estamos'. Analizo el git log con métricas reales y genero un reporte honesto sin fluff.

Úsame cuando el creador terminó de implementar y quiere revisar el código antes de lanzar. También cuando digan 'revisa el código', 'busca bugs', 'code review', o después de terminar una feature. Analizo el diff de la rama, cargo checklists específicos del stack, auto-arreglo lo obvio y escalo lo ambiguo.

Úsame cuando el código está listo, /review y /qa pasaron, y el creador quiere crear el PR. También cuando digan 'lanza', 'crea el PR', 'lanza esto', 'push y PR'. Verifico que todo esté en orden, corro los tests, hago el push y creo el PR con contexto completo.

Úsame al inicio de cada sesión de trabajo, o cuando el creador escriba 'dónde estoy', 'qué falta', 'retomar', 'status' o cualquier variación. Leo el estado del proyecto y le digo al creador exactamente dónde quedó, qué toca hacer ahora y si hay bloqueantes.

Úsame cuando el creador quiera empezar algo nuevo, tenga una idea de feature, o diga 'quiero construir X', 'tengo una idea', 'nuevo sprint', 'empecemos'. Reformulo el problema con preguntas de YC antes de escribir una línea de código. Produzco un design doc que alimenta /plan.

Úsame para desactivar /freeze y volver a poder editar cualquier archivo. Cuando el creador diga 'unfreeze', 'desbloquear', 'sal del freeze', 'ya terminé con eso'.