architecture-mastery

Plugin architecture-mastery from marketplace architecture-mastery in Sebastian-411/generative-clean-software. Commands read from the repo's manifest — 24 days ago.

Skills (9)

• architecture-review

  Orquesta domain-driven-design, hexagonal-architecture, clean-architecture, solid-principles y design-patterns como un solo criterio coherente para diseñar backends nuevos o auditar código existente. Úsala como punto de entrada cuando el usuario pida "diseña esto con DDD + Hexagonal + Clean + SOLID",

• clean-architecture

  Aplica o revisa Clean Architecture - la regla de dependencia (las capas internas no conocen las externas), Use Cases explícitos, y frameworks/DB relegados a los bordes. Úsala cuando el usuario pida estructurar capas de un backend, decidir qué va en cada capa, o auditar si el código de negocio depend

• design-patterns

  Elige o revisa el uso de patrones de diseño GoF (Strategy, Factory, Adapter, Decorator, Observer, Repository, etc.) en el contexto de un backend con DDD/Hexagonal/Clean Architecture. Úsala cuando el usuario pida sugerir un patrón para un problema concreto, nombrar un patrón que ya está usando sin sa

• domain-driven-design

  Modela el dominio de negocio usando Domain-Driven Design - Entities, Value Objects, Aggregates, Bounded Contexts y lenguaje ubicuo. Úsala cuando el usuario pida modelar un dominio complejo, decidir si algo es Entity o Value Object, definir los límites de un Aggregate, separar un monolito en Bounded

• frontend-craft

  Diseño e implementación de páginas y apps al nivel de los mejores sitios reales (Apple, Plada, Founderdex, Vaas, YC, Nike), no generadas por IA. Calibra contra referencias medidas con Playwright (dissect.mjs), consigue contenido real (producto, fotos CC0, cifras), construye sobre plantillas probadas

• greenfield-defaults

  Define el stack y la forma de carpeta cuando se inicia un proyecto desde cero o la carpeta está vacía. Úsala al crear un repo nuevo, scaffold, "proyecto desde 0", o cuando no hay lenguaje/stack definido. No la uses para extender un repo que ya tiene stack — ahí ganan las convenciones existentes. Def

• hexagonal-architecture

  Diseña o revisa un backend usando Arquitectura Hexagonal (Ports & Adapters) - separar el dominio/aplicación de frameworks, DB, colas y HTTP mediante puertos e interfaces. Úsala cuando el usuario pida diseñar un servicio nuevo, aislar el dominio de un framework (NestJS, Spring, Express, Django, etc.)

• solid-principles

  Aplica o revisa los principios SOLID (SRP, OCP, LSP, ISP, DIP) a nivel de clase/módulo. Úsala cuando el usuario pida revisar código por violaciones de SOLID, decidir si una clase hace demasiado, diseñar interfaces, o justificar una abstracción concreta. Trátala como complemento de clean-architecture

• staff-workflow

  Orquesta a los agentes story-writer, architecture-reviewer, planner, implementer, code-reviewer y test-engineer de este plugin como un único proceso de desarrollo adaptativo, igual que lo escalaría un staff engineer - más proceso (con story.md/plan.md en specs/ y checkpoints de aprobación humana) pa

Subagents (7)

• architecture-reviewer

  Agente de solo lectura para auditar el diseño de una feature nueva o el código ya escrito contra el criterio de DDD + Hexagonal + Clean + SOLID + Design Patterns de este plugin, con el Paso 0 anti-overengineering como primer filtro. Úsalo antes de aprobar un PR de arquitectura, antes de implementar

• code-reviewer

  Agente de solo lectura para revisar un diff, PR o rango de commits en busca de bugs de correctitud, oportunidades de simplificación/reuso/eficiencia, y una pasada básica de seguridad (inyección, secretos, XSS, validación de bordes). Complementa a architecture-reviewer - este agente mira el código lí

• design-scout

  Director de arte con navegador. Modo scout - mide referencias reales con Playwright (dissect.mjs sobre los sitios que dé el usuario o los de reference-bar.md; Refero para explorar direcciones), consigue contenido real (photos.mjs, capturas del producto) y deja design/DESIGN.md calibrado (cada valor

• implementer

  Agente con acceso de escritura para implementar una feature o un fix una vez que el nivel de complejidad ya fue decidido (por el agente architecture-reviewer, por la skill architecture-review, o inline si el cambio es obviamente pequeño). Escribe el mínimo código correcto para el problema real, no u

• planner

  Toma el veredicto de architecture-reviewer y el story.md ya aprobado y los convierte en un plan.md ejecutable - fases concretas de implementación, en orden, cada una con su criterio de "hecho". No vuelve a juzgar la arquitectura desde cero (eso ya lo hizo architecture-reviewer) - su trabajo es secue

• story-writer

  Agente que redacta specs/<timestamp>_<slug>/story.md - el qué y el por qué de un cambio mediano/grande/sensible, con criterios de aceptación verificables, antes de que exista ningún diseño o código. Solo lo invoca staff-workflow (o el usuario directo) para cambios ya clasificados como mediano/grande

• test-engineer

  Agente para diseñar y escribir tests (unitarios e integración) del código que implementer acaba de escribir o modificar, y correr el suite completo. Prioriza casos de negocio reales y bordes sobre cobertura por cobertura. Si el cambio toca UI, añade Playwright de diseño (frontend-craft). Solo toca a

Similar plugins