Como usar
- Copie o comando e verifique o pacote antes de instalar no seu ambiente de agente.
- Consulte no original as ferramentas, credenciais e ambientes necessários.
- Descreva os dados de entrada e a entrega esperada; confira a saída com as fontes.
npx skills add https://github.com/adminoryslabs/armory --skill escribir-husAntes de começar
- A instalação não inclui assinatura de modelo, franquia API ou acesso aos seus arquivos.
- Estrelas e instalações indicam atividade, não um teste independente de qualidade ou segurança.
Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.
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).
