directrices-de-arquitectura-de-software

SKILL.md

---
name: directrices-de-arquitectura-de-software
description: Aplica orientación contextual sobre arquitectura de software al analizar los límites del sistema, requisitos de calidad, comunicación, estilos, decisiones, riesgos o evolución.
---

# Directrices de Arquitectura de Software

Utilice este borrador portátil para apoyar el trabajo de arquitectura en diversos dominios de software. No está instalado globalmente. El libro proporciona conceptos y compensaciones; esta guía los operacionaliza como verificaciones condicionales. No son comandos de proyecto ni sustitutos de la intención del usuario, la gobernanza local o la evidencia conocida del sistema.

## Flujo de trabajo

1. **Establecer contexto y autoridad.** Identifique el dominio, el límite del sistema, los resultados de negocio, las restricciones de despliegue y datos, las capacidades del equipo, la evidencia conocida, lo desconocido y la autoridad para tomar decisiones. Respete la autoridad ya delegada. Pregunte solo por hechos faltantes que puedan cambiar el resultado; de lo contrario, dé una recomendación condicional.
2. **Clasificar los impulsores.** Traduza los resultados de los interesados en características arquitectónicas. Pruebe cada candidato contra la definición de tres partes, descomponga cualidades compuestas y priorice un conjunto pequeño.
3. **Mapear límites y datos.** Identifique responsabilidades funcionales, dependencias, transacciones, propiedad de datos, acoplamiento estático, llamadas en tiempo de ejecución y características en cada límite relevante.
4. **Comparar proporcionalmente.** Para una elección trascendental, compare al menos dos opciones viables contra las prioridades, costos, riesgos y evidencia declarados. No fuerce una comparación formal para un cambio pequeño y reversible.
5. **Decidir con justificación.** Declare la recomendación o estado, por qué encaja, costos aceptados, suposiciones y qué evidencia causaría reconsideración. Siga la autoridad delegada; no invente puertas de aprobación.
6. **Especificar verificaciones.** Elija medidas o funciones de aptitud proporcionales al riesgo. Nombre su alcance, señal, limitaciones y respuesta.

## Reglas principales

- Base las recomendaciones en el contexto ([reglas de contexto y prioridad](references/rulebook.md#context-priorities): F01) y respete la autoridad delegada ([reglas de decisión, riesgo y evolución](references/rulebook.md#decisions-risk-evolution): D03).
- Derive y clasifique características a partir de resultados medibles de los interesados ([reglas de contexto y prioridad](references/rulebook.md#context-priorities): F05, F06, F07, F08, F18).
- Mantenga responsabilidades cohesivas y límites honestos sobre dependencias y acoplamiento ([reglas de límites](references/rulebook.md#boundaries-coupling-data): F11–F17, S03, S08; [glosario](references/glossary.md)).
- Elija la comunicación para el trabajo; distinga solicitud, comando y evento, y diseñe para fallos ([reglas de comunicación](references/rulebook.md#communication-reliability): S06, S09–S13, S15, D08).
- Trate los estilos de arquitectura como opciones condicionales y compare sus costos ([reglas de estilo](references/rulebook.md#style-choice): S01, S16, D06; [guía de estilo](references/style-selection.md)).
- Registre por qué existen decisiones trascendentales y qué las cambiaría ([compensaciones](references/rulebook.md#context-priorities): F02; [registros de decisiones](references/rulebook.md#decisions-risk-evolution): F03).
- Haga visible el riesgo, la incertidumbre y la alineación de implementación ([reglas de riesgo y evolución](references/rulebook.md#decisions-risk-evolution): D10, D11, D12, D13).
- Gobierne restricciones importantes con verificaciones que las personas entiendan ([reglas de gobernanza](references/rulebook.md#decisions-risk-evolution): F09, F10).
- Preserve la elección del equipo dentro de la autoridad y restricciones reales ([reglas de equipo y comunicación](references/rulebook.md#communication-teams): S04, D16, D17, D18).
- Aplique orientación específica del proveedor solo cuando el proyecto incluya un proveedor de modelos ([D15 en rules.json](references/rules.json)).

## Contrato de salida

Devuelva: contexto y desconocidos; recomendación y estado; alternativas y costos; implicaciones de límites, datos y comunicación; evidencia y verificaciones; y un disparador de reconsideración. Escale el detalle según la consecuencia de la elección.

## Referencias

Para una tarea, cargue solo la categoría relevante en [rules.json](references/rules.json) o lea su sección en [rulebook.md](references/rulebook.md), no ambos ni todo el paquete. Cargue [style-selection.md](references/style-selection.md) para los nueve estilos, [glossary.md](references/glossary.md) para términos basados en la fuente, y [source-map.json](references/source-map.json) para localizar capítulos citados. Los prompts de evaluación sintética están en [evaluation-cases.json](references/evaluation-cases.json); no se han ejecutado. El método y limitaciones están en [method-and-validation.md](references/method-and-validation.md).