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.
/plugin marketplace add alirezarezvani/claude-cto-team/plugin install cto-team@cto-team-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
decision-matrix.mdpattern-comparison.mdProvides 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.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.