facundomartinezvidal/architect

Software architect for planning and designing new systems and changes to existing packages, modules, layers and whole systems, and for consulting on them. Use for architecture consultation, structural reviews, implementation plans, consequential decisions, domain modeling, documentation and design-level security. Produces analysis, designs, ADRs, diagrams and plans, and leaves implementation to the developer agent. Also covers "revisá este package", "planificá este refactor", "cómo estructuro esto" and "qué conviene usar". Ordinary naming, formatting and unrelated bugs do not need an architecture workflow.

Compares consequential technical options against explicit constraints and quality attributes, or records an agreed decision in an Architecture Decision Record (ADR). Use for "qué conviene usar", costly technology or deployment choices, build vs. buy, migrations, and creating or superseding ADRs. Distinguish advice from recording what a team already accepted. Not for ordinary naming, formatting or small local design choices.

Documents software architecture for a specific audience using C4 context/container/component views, flow or deployment diagrams, and focused class diagrams when type relationships explain the design. Use for architecture overviews, onboarding, stakeholder presentations, "diagrama de arquitectura", "documentá cómo está armado" or a requested view of an established domain model. Derive diagrams from evidence and distinguish current design from proposals. Not for inventing business rules, API reference docs or ER diagrams alone.

Reviews, designs and explains software structure using Robert C. Martin's Clean Architecture — the Dependency Rule, entities and use cases, ports and adapters (hexagonal), SOLID at the module level, component cohesion and coupling (REP/CCP/CRP, ADP/SDP/SAP, instability and abstractness metrics), boundaries, Humble Object, Main as composition root, and packaging. Use it whenever someone asks where code should live, how to structure or layer a project, whether their framework, ORM or database is leaking into business logic, how to split a monolith or draw service boundaries, how to make code testable without the DB or UI, to review a PR or repo for architecture or dependency problems, or what a SOLID or component principle really means — even if they never say "clean architecture". Also covers Spanish requests like "cómo estructuro el proyecto", "revisá la arquitectura", "dónde va esta lógica", "capas", "casos de uso", "puertos y adaptadores", "acoplamiento".

Models and reviews complex business domains using ubiquitous language, bounded contexts, context maps, subdomains and aggregates. Use when business terms conflict, teams share a tangled model, a monolith needs business boundaries, legacy integrations distort the model, or business invariants need explicit consistency and transaction decisions. Also applies to requests such as "cómo modelo este dominio", "contextos delimitados", "agregados" and "lenguaje ubicuo". For dependency direction, layers or folder structure alone, use clean-architecture.

Designs and reviews module interfaces, information hiding and behavioral contracts using A Philosophy of Software Design and The Pragmatic Programmer. Use when callers must know too much, one change spreads across modules, an API requires fragile call ordering, failure or retry semantics are unclear, or abstraction layers add complexity. Covers "cómo diseño esta interfaz", "está sobreingeniería" and "lo separo o lo junto". For system-wide dependency direction use clean-architecture; for business meanings and aggregate invariants use domain-driven-design. Not for formatting or line-level style.

Performs design-level threat modeling with STRIDE — maps assets, data flows and trust boundaries, finds what can go wrong, ranks risks by what actually matters to the system, and proposes mitigations with owners and residual risk. Use it whenever someone is designing or reviewing a system or feature that handles users, money, files, personal data, webhooks, multi-tenancy, external integrations or AI agents, and asks whether the design is secure, what could go wrong, how an attacker could abuse it, or needs a threat model or security design review, even if they never say "STRIDE" or "threat model". Also covers Spanish requests like "es seguro este diseño", "qué riesgos de seguridad tiene", "modelo de amenazas", "cómo lo podrían atacar", "revisión de seguridad de la arquitectura". Not for scanning code for vulnerabilities in a diff, dependency audits, or secret leaks.