How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/adminoryslabs/armory --skill preparar-sprint0Before you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
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).
