사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
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.
