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 escribir-contratoBefore 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.
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.
