Architect

Architect Skill — System Design Expert

This skill provides comprehensive architecture design guidance with evidence-based decision making.

Design Principles

SOLID

• Single Responsibility: One reason to change
• Open/Closed: Open for extension, closed for modification
• Liskov Substitution: Subtypes must be substitutable
• Interface Segregation: Many specific interfaces > one general
• Dependency Inversion: Depend on abstractions, not concretions

CUPID

• Composable: Works well with other components
• Understandable: Clear purpose and usage
• Predictable: Behaves as expected
• Idempotent: Same operation, same result
• Domain-focused: Names and structure reflect the domain

Architecture Patterns

Monolith vs Microservices Decision Matrix

| Factor | Monolith | Microservices | | -------------------- | ----------- | ---------------------- | | Team size | Small (1-5) | Large (5+) | | Deployment frequency | Low | High | | Scaling needs | Uniform | Variable per component | | Complexity | Low | High | | Data consistency | Easy | Hard (eventual) |

Recommended Patterns by Domain

| Domain | Pattern | Why | | ----------- | ------------------ | ------------------------ | | API Layer | Hexagonal/Clean | Testability, flexibility | | Data Access | Repository Pattern | Abstraction from storage | | Events | Event Sourcing | Audit trail, replay | | Caching | Write-through | Consistency | | Auth | RBAC + ABAC | Fine-grained control |

Decision Record Template

## ADR-[N]: [Decision Title]

### Status: PROPOSED | ACCEPTED | DEPRECATED | SUPERSEDED

### Context

[What is the issue that we're seeing that is motivating this decision?]

### Decision

[What is the change that we're proposing/making?]

### Alternatives Considered

1. [Alternative 1]: [Pros] / [Cons]
2. [Alternative 2]: [Pros] / [Cons]

### Consequences

**Positive**: [Benefits]
**Negative**: [Costs/Risks]
**Neutral**: [Side effects]

### Reversibility

[How hard would it be to undo? What is the blast radius?]

Design Review Checklist

• [ ] Requirements clearly understood
• [ ] At least 2 alternatives evaluated
• [ ] Trade-offs documented
• [ ] No circular dependencies introduced
• [ ] Layer boundaries respected
• [ ] Error handling strategy defined
• [ ] Performance characteristics understood
• [ ] Security implications evaluated
• [ ] Testability ensured
• [ ] Documentation planned

When NOT to Use

Do NOT use this skill when:

• Writing application business logic (use domain-driven skill for complete business modules with all sub-modules)
• Designing database schemas (use database-design skill for normalization, indexing, and query optimization)
• Reviewing code for quality issues (use code-review skill for comprehensive code audits)
• Writing API endpoint implementations (use api-design skill for REST/GraphQL endpoint patterns)
• Performing security audits (use security-auditor skill for vulnerability analysis and threat modeling)
• Analyzing deployment configurations (use deployment skill for CI/CD pipelines and infrastructure)
• Writing SQL queries (use sql-best-practices skill for query optimization and N+1 prevention)
• Reviewing git workflows (use git-workflow skill for branching strategies and commit conventions)
• Redesigning existing websites (use website-redesign skill for UI/UX improvements from URLs/screenshots)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Omar-Obando
• Source: Omar-Obando/qwen-orchestrator
• License: MIT
• Homepage: https://qwen.ai/qwencode

Install and usage instructions live in the source repository linked above.