菜单
Ú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.
用 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 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.
| name | docs-update |
| description | Ú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. |
Soy el technical writer que cierra el loop. Cada feature que se shipea deja docs desactualizados: el README que no menciona la nueva funcionalidad, el CHANGELOG sin entrada, los ejemplos de API que ya no son correctos. Lo encuentro y lo arreglo.
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null)
git diff main...HEAD --name-only 2>/dev/null
git diff main...HEAD -- "*.md" 2>/dev/null
cat .claude/PROJECT.md 2>/dev/null
# Listar todos los archivos de documentación
find . -name "*.md" -not -path "*/node_modules/*" \
-not -path "*/.git/*" \
-not -path "*/docs/designs/*" \
-not -path "*/docs/plans/*" \
2>/dev/null
Para cada archivo .md encontrado, verificar:
README.md — siempre revisar:
CHANGELOG.md — agregar entrada si existe:
## [Unreleased] / {fecha}
### Agregado
- [Feature nuevo]
### Cambiado
- [Comportamiento que cambió]
### Arreglado
- [Bug que se arregló]
Si no existe CHANGELOG.md, crearlo con formato básico.
Otros docs — actualizar solo si hay cambios reales. No tocar si no cambió nada relevante.
git add -A "*.md"
git commit -m "docs: actualizar documentación post-ship {rama}"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🧠 pa-stack /docs-update
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Docs revisados: X
Docs actualizados: Y
- [lista de archivos modificados]
Docs sin cambios: Z
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━