From alfred-dev
Designs system architecture using Mermaid component and sequence diagrams, module contracts, and SOLID principles. Useful for defining components, flows, project structure, and service organization.
npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-devThis skill uses the workspace's default tool permissions.
Este skill produce el diseño arquitectónico de un sistema o módulo, incluyendo diagramas de componentes, contratos entre módulos y decisiones de diseño fundamentales. El resultado es un documento que permite a cualquier desarrollador del equipo entender cómo encajan las piezas antes de escribir código.
Create architecture diagrams using Mermaid, PlantUML, C4 model, flowcharts, and sequence diagrams for documenting system design, data flows, and technical workflows.
Generates system architecture docs with overview, components list, Mermaid diagrams for components and data flows, external dependencies, ADRs links, and dev setup instructions.
Guides design of system architecture, APIs, components, data models via workflow with requirements, validation, and spec/diagram outputs.
Share bugs, ideas, or general feedback.
Este skill produce el diseño arquitectónico de un sistema o módulo, incluyendo diagramas de componentes, contratos entre módulos y decisiones de diseño fundamentales. El resultado es un documento que permite a cualquier desarrollador del equipo entender cómo encajan las piezas antes de escribir código.
La arquitectura no se diseña para impresionar, sino para comunicar. Los diagramas deben ser claros, los contratos precisos y las decisiones justificadas.
Entender los requisitos. Leer el PRD si existe. Identificar los requisitos funcionales (qué hace el sistema) y los no funcionales (rendimiento, escalabilidad, seguridad, disponibilidad). Los requisitos no funcionales suelen ser los que más condicionan la arquitectura.
Definir los componentes principales. Identificar los módulos, servicios o capas del sistema. Para cada componente, documentar:
Generar diagrama de componentes con Mermaid:
graph TD
A[Cliente] --> B[API Gateway]
B --> C[Servicio Auth]
B --> D[Servicio Core]
D --> E[(Base de datos)]
D --> F[Cola de mensajes]
El diagrama debe mostrar los componentes y sus relaciones, no los detalles internos de cada uno.
Generar diagrama de secuencia para los flujos críticos:
sequenceDiagram
participant U as Usuario
participant A as API
participant D as DB
U->>A: POST /recurso
A->>D: INSERT
D-->>A: OK
A-->>U: 201 Created
Cubrir al menos el happy path y el principal flujo de error.
Definir contratos entre módulos. Para cada interfaz entre componentes, especificar:
Aplicar principios SOLID. Verificar que el diseño respeta:
Documentar decisiones no obvias. Si se elige un patrón (Event Sourcing, CQRS, Hexagonal, etc.), explicar por qué es adecuado para este caso y qué alternativas se descartaron.
Registrar las decisiones arquitectónicas principales en la memoria del proyecto. Usar memory_log_decision para cada decisión significativa (elección de patrón, estrategia de comunicación entre servicios, estructura de capas, etc.). Esto permite que futuros skills y sesiones tengan contexto sin releer todo el documento.
Revisar con el usuario. La arquitectura es una decisión de equipo. Presentar el diseño, recoger feedback e iterar antes de implementar.