Design system architecture, APIs, and component interfaces. Use for architectural decisions and system design.
Install
npx skillscat add htlin222/dotfiles/architect Install via the SkillsCat registry.
This skill designs system architectures, APIs, and component interfaces to ensure scalability and maintainability. It solves the problem of making complex structural decisions by providing frameworks for trade-off analysis and architectural patterns. Developers or agents should use it during system design discussions, major refactors, or when documenting architectural decision records.
System Architecture
Design scalable, maintainable system architectures.
When to Use
- Major architectural decisions
- System design discussions
- Evaluating trade-offs
- Planning large refactors
- Reviewing system structure
Design Process
- Understand - Clarify requirements and constraints
- Identify - Define components and boundaries
- Design - Create architecture with trade-offs
- Validate - Check against requirements
- Document - Record decisions and rationale
Architecture Patterns
Layered Architecture
┌─────────────────────────────┐
│ Presentation Layer │ UI, API endpoints
├─────────────────────────────┤
│ Business Layer │ Domain logic, services
├─────────────────────────────┤
│ Persistence Layer │ Repositories, DAOs
├─────────────────────────────┤
│ Data Layer │ Database, cache
└─────────────────────────────┘Microservices
┌─────────┐ ┌─────────┐ ┌─────────┐
│ User │ │ Order │ │ Payment │
│ Service │ │ Service │ │ Service │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└────────────┼────────────┘
│
┌──────┴──────┐
│ Message Bus │
└─────────────┘Event-Driven
Producer → Event Bus → Consumer(s)
│
├→ Service A
├→ Service B
└→ AnalyticsDecision Framework
Trade-off Analysis
| Aspect | Option A | Option B |
|---|---|---|
| Complexity | Low | High |
| Scalability | Limited | Horizontal |
| Cost | $ | $$$ |
| Time to market | Fast | Slow |
| Maintenance | Easy | Complex |
ADR Template
# ADR-001: [Decision Title]
## Status
Accepted | Proposed | Deprecated
## Context
[Why we need to make this decision]
## Decision
[What we decided]
## Consequences
### Positive
- [Benefit 1]
### Negative
- [Trade-off 1]
### Risks
- [Risk 1]Key Principles
- Separation of Concerns - Each component has one responsibility
- Loose Coupling - Minimize dependencies between components
- High Cohesion - Related functionality grouped together
- YAGNI - Don't build for hypothetical requirements
- Fail Fast - Detect and report errors immediately
Scalability Checklist
- Stateless services (session in Redis/DB)
- Horizontal scaling capability
- Database read replicas
- Caching layer (Redis, CDN)
- Async processing for heavy tasks
- Rate limiting and circuit breakers
Examples
Input: "Design a notification system"
Action: Define channels, queue architecture, delivery guarantees, scaling strategy
Input: "Should we use microservices?"
Action: Analyze team size, complexity, scaling needs, recommend with trade-offs