// Recommend architecture patterns (monolith, microservices, serverless, modular monolith) based on scale, team size, and constraints. Use when cto-architect needs to select the right architectural approach for a new system or migration.
Detect common technical and organizational anti-patterns in proposals, architectures, and plans. Use when strategic-cto-mentor needs to identify red flags before they become problems.
Identify and challenge implicit assumptions in plans, proposals, and technical decisions. Use when strategic-cto-mentor needs to surface hidden assumptions and wishful thinking before they become costly mistakes.
Generate targeted clarifying questions (2-3 max) that challenge vague requirements and extract missing context. Use after request-analyzer identifies clarification needs, before routing to specialist agents. Helps cto-orchestrator avoid delegating unclear requirements.
Infrastructure and development cost estimation for technical projects. Use when planning budgets, evaluating build vs buy decisions, or projecting TCO for architecture choices.
Transform clarified user requests into structured delegation prompts optimized for specialist agents (cto-architect, strategic-cto-mentor, cv-ml-architect). Use after clarification is complete, before routing to specialist agents. Ensures agents receive complete context for effective work.
Deep expertise in ML/CV model selection, training pipelines, and inference architecture. Use when designing machine learning systems, computer vision pipelines, or AI-powered features.
| name | architecture-pattern-selector |
| description | Recommend architecture patterns (monolith, microservices, serverless, modular monolith) based on scale, team size, and constraints. Use when cto-architect needs to select the right architectural approach for a new system or migration. |
Provides systematic framework for selecting the right architecture pattern based on real-world constraints rather than hype or resume-driven development.
Best for: Early-stage products, small teams, rapid iteration
Characteristics:
Choose when:
Avoid when:
Best for: Growing products that need structure without microservices complexity
Characteristics:
Choose when:
Avoid when:
Best for: Large organizations with mature DevOps practices
Characteristics:
Choose when:
1M users with varying load patterns
Avoid when:
Best for: Event-driven workloads, variable traffic, cost optimization
Characteristics:
Choose when:
Avoid when:
Best for: Complex systems with varied requirements
Characteristics:
Choose when:
Team Size: [ ] < 10 [ ] 10-30 [ ] 30-100 [ ] > 100
User Scale: [ ] < 100K [ ] 100K-1M [ ] 1M-10M [ ] > 10M
DevOps Maturity: [ ] None [ ] Basic [ ] Intermediate [ ] Advanced
Deployment Freq: [ ] Monthly [ ] Weekly [ ] Daily [ ] Multiple/day
| Constraint | Impact on Pattern Choice |
|---|---|
| Time to market | Favors monolith |
| Team autonomy | Favors microservices |
| Cost sensitivity | Favors serverless or monolith |
| Latency requirements | Disfavors serverless |
| Compliance/security | May require isolation (microservices) |
See decision-matrix.md for the scoring framework.
Every architecture should have a migration path:
When recommending an architecture pattern, provide:
## Architecture Recommendation
### Recommended Pattern: [Pattern Name]
**Confidence**: High / Medium / Low
### Why This Pattern
[2-3 specific reasons based on constraints]
### Trade-offs Accepted
- [Trade-off 1 and why it's acceptable]
- [Trade-off 2 and why it's acceptable]
### Migration Path
- **Current**: [Current state]
- **Phase 1**: [Near-term architecture]
- **Phase 2**: [If/when to evolve]
- **Trigger**: [What would cause migration to next phase]
### Patterns Rejected
| Pattern | Reason Not Selected |
|---------|---------------------|
| [Pattern] | [Specific reason] |
### Implementation Considerations
- [Key consideration 1]
- [Key consideration 2]
- [Key consideration 3]
Choosing microservices because it looks good on resumes, not because the problem requires it.
Red flag: "We should use microservices because that's what Netflix uses." Reality check: You're not Netflix. What's your actual scale and team size?
Distributing a system before understanding the domain boundaries.
Red flag: "Let's start with microservices from day one." Reality check: You'll draw the wrong boundaries. Start monolith, extract when clear.
Equating complexity with sophistication.
Red flag: "Our architecture needs to be enterprise-grade." Reality check: Simple architectures that work beat complex ones that don't.