Mode d’emploi
- Copiez la commande et examinez le paquet avant de l’installer dans votre environnement agent.
- Consultez le document original pour les outils, identifiants et environnements requis.
- Décrivez les entrées et le livrable souhaité ; comparez la sortie aux sources.
npx skills add https://github.com/adminoryslabs/armory --skill escribir-contratoAvant de commencer
- L’installation n’inclut ni abonnement au modèle, ni quota API, ni accès aux fichiers.
- Étoiles et installations reflètent l’activité, pas un test indépendant de qualité ou de sécurité.
Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.
Escribir contrato
Goal
Producir el único documento que leen el TESTER y el DEV: lo que la HU tiene que hacer vista desde afuera, con la precisión suficiente para que dos agentes que no se ven lleguen al mismo resultado. El contrato fija lo observable; lo interno queda libre para el DEV.
Esta skill no construye nada. Escribe, pregunta y se detiene.
Input
- La HU — desde Jira vía MCP si está conectado, o el archivo/enlace indicado. Si tiene puntos
abiertos sin resolver, detenerse: se escalan antes de escribir el contrato.
TECH-DESIGN.md— la sección y los criterios de aceptación que corresponden a esta HU.adrs/— solo los ADRs de historia de esta HU (y los transversales que condicionan su
interfaz, ej. estilo de API).
AGENTS.md— convenciones del proyecto.- Contratos anteriores en
contratos/— para no contradecir nombres ya fijados.
Workflow
- Armar el paquete de contexto: HU + ADRs que aplican + sección del TDD. Nada más. Listar
qué entró al paquete y por qué.
- Identificar la interfaz observable por la que se usa la funcionalidad (una ruta HTTP, una
pantalla, un comando, un evento…). El contrato se escribe sobre esa interfaz.
- Por cada escenario Gherkin y cada criterio de aceptación del TDD, derivar los casos:
- entrada exacta (ruta, parámetros, formato);
- salida exacta por caso (status, datos, texto visible, efecto persistente);
- errores (qué entrada inválida produce qué respuesta).
- Fijar los nombres que no se negocian: rutas, campos, mensajes visibles, formatos. Son los
que el TESTER verificará textualmente.
- Anotar el origen de cada línea (escenario Gherkin, criterio del TDD, ADR). Una línea sin
origen es una decisión nueva: se marca DECISIÓN PROPUESTA y entra en la lista de preguntas para el humano. Nunca se presenta como si viniera de la HU.
- Declarar qué queda fuera del contrato (todo lo interno: estructura, nombres de funciones,
consultas) → libertad del DEV.
- Guardar
contratos/CONTRATO-<HU>.mdconassets/contrato-template.md, versiónv1.
- Detenerse. Presentar el contrato y las preguntas al humano. No invocar a nadie.
Versionado
Cuando durante el ciclo aparece un hueco (lo reporta el TESTER, el DEV o el veredicto):
- se formula la pregunta al humano;
- con la respuesta, se edita el contrato, se sube la versión (
v2,v3…) y se agrega una fila
al changelog (qué cambió, por qué, quién lo aprobó);
- el LEAD avisa a TESTER y DEV de la nueva versión.
Constraints
- No se completa con suposiciones lo que la HU no dice: se pregunta.
- No se describe implementación interna en el contrato.
- No se contradice un nombre fijado en un contrato anterior sin decirlo explícitamente.
- No se publica nada.
