Cómo usar
- Copia el comando y revisa el paquete antes de instalarlo en tu entorno de agente.
- Consulta las herramientas, credenciales y entornos necesarios en el documento original.
- Describe las entradas y el resultado deseado; contrasta la salida con las fuentes.
npx skills add https://github.com/adminoryslabs/armory --skill preparar-sprint0Antes de empezar
- La instalación no incluye suscripción al modelo, cuota API ni permisos sobre tus archivos.
- Las estrellas e instalaciones reflejan actividad, no una prueba independiente de calidad o seguridad.
Contenido del repositorio de origen con títulos, ejemplos, código, tablas, enlaces e imágenes preservados.
Preparar Sprint 0
Goal
Convertir "inicializa el proyecto" en una unidad de trabajo acotada y verificable: el esqueleto mínimo que funciona de punta a punta, sin lógica de negocio. El resultado es un único documento, SPRINT0.md, que leen por igual el TESTER y el DEV.
Esta skill no construye nada. Prepara, propone y se detiene.
Input
TECH-DESIGN.mdyadrs/— obligatorios. Si faltan, detenerse y pedirlos.AGENTS.mdy/oCLAUDE.mddel proyecto — si existen, se leen y luego se actualizan (paso 5).- HUs — no se leen para construir. Solo se consultan para saber a qué historia pertenece cada
ADR de historia.
Workflow
- Leer el Tech Design y todos los ADRs.
- Clasificar cada ADR en una de tres categorías, con una línea de justificación:
- Transversal — se necesita para que el proyecto exista (stack, estructura, estilo de API,
ORM, manejo de estado general). Aplica en el Sprint 0.
- De historia — resuelve una funcionalidad concreta. No aplica en el Sprint 0; se anota
a qué HU(s) pertenece.
- Mixto / a discutir — parte es transversal y parte es de historia. Se explica qué parte
aplica ahora y se marca para que el humano lo confirme. Pregunta guía: "¿Esto lo necesito para que el proyecto exista, o para una funcionalidad concreta?"
- Definir el mapa de propiedad de rutas según el stack real del proyecto (no según un stack
asumido):
- TESTER — las rutas donde viven las pruebas según la convención del framework de pruebas
elegido (y sus fixtures o datos de prueba).
- DEV — el código de la aplicación, su configuración, migraciones y el manifiesto de
dependencias.
- Solo LEAD / humano — los archivos del harness:
AGENTS.md,CLAUDE.md, carpetas de
skills y de configuración de agentes, SPRINT0.md, contratos. Si una ruta no encaja claramente, se marca como pregunta para el humano.
- Escribir la Definition of Done del esqueleto. Cada punto debe ser verificable y decir
cómo se verifica (prueba o comando). Mínimo:
- la aplicación arranca en local;
- se conecta a sus dependencias principales (ej. base de datos), si los ADRs transversales las
incluyen;
- existe un punto de verificación de salud (ej. una ruta o comando de health) con nombre exacto;
- el runner de pruebas está instalado, configurado y se ejecuta;
- respeta los ADRs transversales;
- cero lógica de negocio.
Los nombres exactos (rutas, comandos) se escriben en la DoD: son el contrato mínimo que permite a TESTER y DEV trabajar sin verse.
- Escribir el plan usando
assets/sprint0-template.md: qué crea el DEV, qué crea el TESTER,
y qué NO se crea (todo lo que pertenece a ADRs de historia).
- Guardar `SPRINT0.md` en la raíz del proyecto y agregar el mapa de propiedad de rutas a
AGENTS.md (y a CLAUDE.md si también existe), en una sección ## Propiedad de rutas.
- Detenerse. Presentar al humano: la clasificación de ADRs, el mapa de rutas, la DoD y el
plan, más la lista de preguntas abiertas. No invocar a nadie ni crear archivos de aplicación. Si el humano pide cambios, se ajusta SPRINT0.md y se vuelve a presentar.
Constraints
- No se implementa ningún ADR de historia, aunque parezca trivial.
- No se elige un stack que los ADRs no fijan: si falta una decisión, es una pregunta.
- Un punto de la DoD que no se puede verificar no entra en la DoD.
- No se publica nada (ni push a main, ni deploy).
