使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/adminoryslabs/armory --skill escribir-contrato开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
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.
