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 escribir-husAntes 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.
Escribir HUs
Goal
Traducir un PRD en Historias de Usuario accionables, sin importar el dominio del proyecto (salud, fintech, retail o cualquier otro): cada HU tiene que poder construirse sin que nadie adivine lo que el PRD no dice.
Input
- PRD con 5 secciones (el formato es constante; el dominio varía y nunca se asume):
- Problema
- Objetivo
- Alcance (Incluye / No incluye)
- Supuestos y Puntos Abiertos
- Criterios de éxito
- Si el sistema ya existe y fue contextualizado:
docs/contexto/GLOSARIO.mdy
docs/contexto/CAPACIDADES.md. Las HUs usan los términos del glosario y no duplican capacidades que el sistema ya tiene.
Si el PRD no trae alguna sección, adaptarse sin cambiar el proceso (por ejemplo, extraer el objetivo del Problema) y dejarlo dicho.
Workflow
- Leer las 5 secciones completas antes de escribir nada. El Alcance marca los límites; los
Puntos Abiertos marcan lo que todavía no está decidido.
- Identificar las funcionalidades claras del Alcance. Cada una se convierte en una HU: no
combinar varias en una HU gigante ni fragmentar de más creando HUs artificiales para sub-pasos de una misma acción.
- Detectar conflictos entre secciones antes de resolverlos. Si el Alcance, el Objetivo y los
Criterios de éxito no dicen lo mismo, no se decide en silencio: se documenta el conflicto y se construye solo lo mínimo necesario para cumplir el criterio, dejando explícito que falta confirmación de negocio.
- Redactar cada HU con
assets/hu-template.md: Historia (Como/Quiero/Para) + al menos 2
escenarios Gherkin (camino feliz + 1 caso borde).
- Reglas de negocio transversales (por ejemplo, un Criterio de éxito que aplica a varias
funcionalidades) se validan como escenario borde dentro de cada HU afectada, no como una HU aparte.
- Ningún dato no confirmado por el PRD se asume por conveniencia. Se declara como Punto
Abierto con la pregunta exacta que se le haría al negocio.
- Nada de lo marcado "No incluye" se agrega, aunque parezca una mejora obvia.
- Los Puntos Abiertos se reparten solo en las HUs donde aplican literalmente, no se copian
todos en todas las HUs por defecto.
- Un archivo Markdown por HU, guardado en la carpeta del proyecto.
Quality gate
- [ ] Leí las 5 secciones del PRD (no solo el Alcance)
- [ ] Cada HU corresponde a una funcionalidad clara del Alcance: ni combinada ni fragmentada de más
- [ ] Cada HU tiene mínimo 2 escenarios Gherkin (camino feliz + caso borde)
- [ ] Ningún dato asumido aparece redactado como si ya estuviera decidido
- [ ] Nada de la lista "No incluye" se coló como funcionalidad
- [ ] Cada Punto Abierto trae la pregunta exacta al negocio, no una suposición disfrazada
- [ ] Los conflictos entre secciones del PRD quedaron documentados, no resueltos en silencio
- [ ] Si el sistema estaba contextualizado: usé los términos del glosario y no dupliqué capacidades
- [ ] Un archivo Markdown por HU, guardado en la carpeta del proyecto
References
assets/hu-template.md— plantilla de HU.references/ejemplos-aplicados.md— casos resueltos en proyectos anteriores (conflictos de
alcance, puntos abiertos, elementos fuera de alcance propuestos por otro agente).
