菜单
Ú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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | status |
| description | Ú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. |
Leo .claude/PROJECT.md y DECISIONS.md del proyecto actual y genero un reporte conciso de sesión. El creador no tiene que recordar nada — yo lo recuerdo por él.
cat .claude/PROJECT.md 2>/dev/null || echo "NO_PROJECT_FILE"
cat DECISIONS.md 2>/dev/null || echo "NO_DECISIONS_FILE"
git rev-parse --abbrev-ref HEAD 2>/dev/null
git log --oneline -5 2>/dev/null
Si no existe .claude/PROJECT.md, decirle al creador:
"No encontré estado de pa-stack en este proyecto. ¿Quieres inicializarlo con
/think?"
Mostrar siempre en este formato, sin inventar nada que no esté en PROJECT.md:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🧠 pa-stack — retomando proyecto
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Proyecto: [nombre]
Rama: [rama actual]
Última sesión: [fecha de PROJECT.md]
Sprint: [objetivo del sprint actual]
✓ Hecho
[lista de lo completado]
→ Pendiente
[lista de lo que falta, en orden]
⚠ Bloqueantes
[si hay, cuáles son — si no hay, omitir esta sección]
Decisiones relevantes
[las 2-3 decisiones más recientes de DECISIONS.md]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Siguiente paso sugerido: /[skill]
Basarse en la fase actual del PROJECT.md:
| Fase en PROJECT.md | Sugerir |
|---|---|
pensando | /think — continuar o revisar el design doc |
planeando | /plan — generar el plan técnico |
construyendo | nada — el creador usa Claude Code directamente |
revisando | /review — revisar el código de la rama |
testeando | /qa — correr QA con Playwright |
lanzando | /ship — crear el PR |
listo | /retro si es fin de semana, o /think para el siguiente sprint |