architecture-decision-recordCrea un Registro de Decisión de Arquitectura (ADR) para cualquier decisión técnica. Úsalo cuando necesites documentar una decisión técnica, escribir un ADR, registrar una elección arquitectónica o capturar por qué se seleccionó una tecnología o enfoque. Produce un ADR estructurado con contexto, decisión, consecuencias e intercambios.
Independent GitHub snapshot · Automated classification · Original documentation governs
Esta habilidad produce un Registro de Decisión de Arquitectura (ADR) completo siguiendo el formato Nygard — el estándar más ampliamente adoptado. Los ADRs documentan el razonamiento detrás de decisiones técnicas significativas para que los futuros miembros del equipo entiendan no solo qué se decidió, sino por qué.
Trabaja con lo que se proporciona. Si falta algo de esto, aun así produce el resultado completo: rellena cada vacío con una suposición razonable marcada como (asumido, confirmar) y lista esas suposiciones al final. Solo haz una pregunta cuando falta el tema central en sí (no hay nada sobre lo que escribir).
Fecha: [YYYY-MM-DD] Estado: [Propuesto / Aceptado / Deprecado / Reemplazado por ADR-NNN] Autor(es): [Nombre(s)] Responsables de la decisión: [Quién tuvo la palabra final — individuo o equipo]
[3–6 oraciones. Describe la situación, restricciones y fuerzas en juego que hicieron necesaria esta decisión. Incluye: el problema a resolver, estado relevante del sistema, restricciones del equipo, presiones de cronograma o requisitos innegociables. Escribe como si explicaras a alguien que se une al equipo 18 meses después sin contexto previo.]
Restricciones clave:
Para cada opción, produce:
Descripción: [Qué es esta opción — 1–3 oraciones]
Ventajas:
Desventajas:
Por qué fue descartada (si no fue elegida): [Razón honesta]
Usaremos [opción elegida].
[2–4 oraciones explicando la decisión en lenguaje plano. Debería ser legible de forma aislada — alguien debería entender la decisión solo con este párrafo sin leer el documento completo.]
[Incluye si la decisión tiene gotchas de implementación no obvios, o si hay tickets/RFCs relacionados que los implementadores necesitarán. Omite solo si la decisión es puramente selección de herramientas sin ambigüedad de implementación.]
[Incluye a menos que la decisión sea permanente o evidentemente final. Establece una condición de disparo específica — p. ej. "Revisar si el equipo crece más allá de 20 ingenieros o el tráfico supera 10M requests/día" — no solo "debería revisarse periódicamente".]
Esta habilidad se entrega con archivos de apoyo — úsalos cuando estén disponibles:
references/decision-scoping.md — Qué Merece un ADR (y Qué Debe Contener el "Contexto"). Aplícalo mientras produces el resultado; contiene los juicios y decisiones de calibración que el resumen del método anterior comprime.templates/adr.md — una versión para rellenar del entregable con los gates de calidad inline. Ofrécela cuando el usuario quiera trabajar el documento él mismo en lugar de tenerlo generado.Puntúa cualquier salida de esta habilidad antes de entregarla; 32+ es de calidad para producción.
| Dimensión | 0 | 5 | 10 |
|---|---|---|---|
| Reconstrucción del contexto | Asume que el lector ya conoce el problema y las presiones | Problema enunciado, pero faltan las fuerzas (restricciones del equipo, escala, plazo, evento que fuerza) | Un lector dos años después podría adivinar la decisión solo desde la sección de Contexto |
| Honestidad de opciones | Solo la opción elegida, u opciones rechazadas escritas como espantapájaros | ≥2 opciones, pero las razones de rechazo son circulares ("no cumplieron los requisitos") | Cada opción rechazada tiene fortalezas genuinas y una restricción perdedora específica vinculada a una presión del contexto |
| Balance de consecuencias | Todas las consecuencias son positivas | Negativas simbólicas sin especificidades operacionales | Los negativos nombran deudas reales, nuevas cargas operacionales y qué debe mantenerse verdadero para que la decisión se sostenga |
| Disparadores de revisión | No se indican riesgos o condiciones de revisión | "Revisar periódicamente" — sin condición medible | Condiciones de disparo específicas y medibles que invalidarían la decisión, con un responsable |