Índice de comandos

Qué comando y qué skill se usa en cada fase, y cuáles son propios de Argui frente a los que trae el asistente.

README.md/50 líneas

metodologia/templates/commands/README.md
# Comandos y skills de Argui

Índice de los **comandos y skills** que Argui entrega o recomienda, y **en qué fase** se usa
cada uno. Son aceleradores: la metodología funciona sin ellos (principio de portabilidad —
[portability.md](../../methodology/portability.md)), pero con el asistente adecuado ahorran
trabajo y mantienen consistencia.

Los **comandos** de esta carpeta son plantillas: cópialos a `.claude/commands/` de tu proyecto
y rellena los `[corchetes]`.

## Qué puede ser un comando (y qué no)

Un **comando Argui = una unidad de trabajo**. Por eso:

- **Cabe en un solo contexto** y **cierra en un punto de limpieza** (commit + `/clear`).
- Es **stateless entre invocaciones**: el estado vive en archivos (CLAUDE.md, backlog, specs), no
  en el contexto.
- Es **quirúrgico**: no reconstruye el proyecto desde cero, agrega sobre lo que ya está.
- **Nunca cruza un `/clear`.** La limpieza de contexto ocurre **entre** invocaciones, no dentro de
  una — `prototype-adjust` lo dice explícito ("limpio contexto entre ajustes").

De ahí la regla: los **rituales repetidos de una unidad** son buenos comandos (prototype-adjust,
auditoria, el ciclo `/opsx:*`, recuperar-zona); los **procesos multi-unidad o de una sola vez** (p.
ej. el onboarding brownfield, el arranque de fases 0–4) **no se meten en un comando** — se documentan
como secuencia, cada paso su propia unidad. Forzar un proceso multi-unidad en un comando rompería la
disciplina de limpieza de contexto ([operations.md](../../methodology/operations.md)).

## Catálogo

| Comando / skill | Fase | Qué hace | Dónde vive |
|---|---|---|---|
| **prototype-adjust** | 3 | Ciclo de ajuste del prototipo de a uno, con confirmación humana; al confirmar, propaga a design system y PRD (Product Requirements Document) (la DoD hecha comando). | Aquí: [`prototype-adjust.md`](./prototype-adjust.md) |
| **Andamiaje de prototipo** | 3 | Modo demo, insignias `data-prd` clicables, comentario por bloque (export Markdown/JSON), Formspree opcional, validación de consistencia §↔PRD. Mecanismo + envoltorio de skill. | [`templates/prototype/`](../prototype/) |
| **Stage `qa` de OpenSpec** | 5 | La etapa de QA (Quality Assurance) del ciclo personalizado (apply → verify → qa → archive). | [`templates/openspec/`](../openspec/) |
| **Revisiones empaquetadas del asistente** (p. ej. `/code-review`, `/security-review`) | 5 | Atajos para los pases 2 y 3 de `verify` — revisión de código y, cuando el gate de superficie sensible lo marca, de seguridad. Opcionales y volátiles: el pase está definido como responsabilidad del agente revisor. | Externo — ver [dependencies.md](../../methodology/dependencies.md), [portability.md](../../methodology/portability.md) |
| **find-skills** (`vercel-labs`) | 0 | Meta-skill que descubre e instala las demás skills del proyecto. Se instala temprano. | Externo — ver [dependencies.md](../../methodology/dependencies.md) |
| **Skills de dominio** (p. ej. `frontend-design`) | 3, 5 | Las que cada agente declara y usa siempre para tareas que lo justifiquen. Se descubren con find-skills. | Externo — ver [agents.md](../../methodology/agents.md), [dependencies.md](../../methodology/dependencies.md) |
| **metaprompt** | transversal | Ayuda a redactar prompts de calidad (Expertise/`description` de agentes, `instruction` de los stages de OpenSpec, prosa de skills). Genérico, no específico de Argui. | Aquí: [`metaprompt.md`](./metaprompt.md) |
| **auditoria** | transversal (cadencia fases 5–6) | Corre la auditoría periódica —specs↔código, tokens, salud de la suite + **métricas de entrega**—, emite el artefacto fechado y actualiza el índice. | Aquí: [`auditoria.md`](./auditoria.md) |
| **recuperar-zona** | 6 (brownfield) | Recupera un módulo antes de tocarlo: arqueología puntual → completar su spec → corrige el PRD técnico. Ritual repetido de la Fase 6 brownfield. | Aquí: [`recuperar-zona.md`](./recuperar-zona.md) |

## Cómo se relaciona con el resto

- **"Cuándo y cómo usar"** cada uno vive en el doc de su fase (el ciclo de ajustes en
  [prototype.md](../../methodology/prototype.md); el metaprompt como nota en
  [agents.md](../../methodology/agents.md)). Esta tabla es el índice, no el manual.
- **Qué pasa si una herramienta externa falta o cambia de versión** está en
  [dependencies.md](../../methodology/dependencies.md), ordenado por riesgo. Eje distinto al de
  esta tabla (que ordena por *cuándo se usa*).