architecture-selection
Architecture Selection helps teams pick the best system design by evaluating patterns against team size, domain complexity, scaling needs, and operational maturity. It scores candidates using weighted criteria, documents trade-offs, and provides migration paths—avoiding resume-driven choices and premature optimization. Use it to design new systems, plan migrations, or review existing architectures.
Architecture Selection guides you through evaluating monolith, microservices, event-driven, and serverless patterns to match your system's needs.
AI-generated summary based on this skill's SKILL.md
Install
rsmdt/the-startup/architecture-selection · repository language: Shell
git clone https://github.com/rsmdt/the-startup
cp -r the-startup/plugins/team/skills/development/architecture-selection ~/.claude/skills/architecture-selectionnpx skillfed install rsmdt/the-startup/architecture-selectionFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do I pick the right architecture pattern for my system?
Architecture Selection helps you evaluate patterns—monolith, microservices, serverless, and event-driven—against your specific requirements. Score candidates using weighted criteria including team size, domain complexity, scaling needs, and operational maturity. The skill guides you through trade-off analysis so you avoid resume-driven choices and premature optimization, then documents your decision using ADR format for future reference.
What are the monolith vs microservices tradeoffs I should consider?
Architecture Selection breaks down key trade-offs: monoliths offer simpler deployment and lower ops overhead but limit independent scaling; microservices enable team autonomy and targeted scaling but require mature DevOps practices. The skill helps you assess whether your team's operational maturity, domain complexity, and scaling requirements justify microservices' added complexity, or whether a monolith better fits your current stage.
When should I use serverless vs microservices architecture?
Architecture Selection compares serverless and microservices across criteria like cost predictability, latency requirements, vendor lock-in tolerance, and team expertise. Serverless suits event-driven workloads with variable traffic and minimal ops burden; microservices work better for complex domains needing fine-grained control. The skill helps you weight these factors against your system's actual constraints rather than hype.
How does team size affect architecture selection?
Architecture Selection recognizes that team size and operational maturity directly influence which patterns are viable. Smaller teams typically benefit from monoliths or managed serverless to minimize ops overhead; larger teams with DevOps expertise can sustain microservices. The skill assesses your team's capabilities as a weighted criterion, helping you choose an architecture your organization can actually operate effectively.
How do I plan a migration from monolith to microservices?
Architecture Selection provides migration paths by first documenting your current architecture's constraints, then identifying service boundaries aligned with your domain. It helps you stage the transition—perhaps starting with a strangler pattern or extracting high-value services first—while assessing team readiness and ops maturity. The skill ensures your migration plan matches your team's capacity rather than forcing a risky big-bang rewrite.
What should I document when making an architecture decision?
Architecture Selection guides you through ADR (Architecture Decision Record) format: capture the decision, context, alternatives considered, trade-offs, and consequences. This creates a searchable record of why you chose your pattern, making it easier to revisit decisions later and onboard new team members. The skill helps you document not just the choice but the reasoning behind it.
SKILL.md
rendered from the published skill — quoted content, verbatim
Persona
Act as a system architecture advisor who guides teams in selecting and implementing architecture patterns matched to their requirements, team capabilities, and scalability needs. You balance pragmatism with forward-thinking design.
Architecture Target: $ARGUMENTS
Interface
EvaluationCriteria { teamSize: string // e.g., "< 10", "> 20" domainComplexity: SIMPLE | MEDIUM | COMPLEX scalingNeeds: UNIFORM | VARIED | ASYNC | UNPREDICTABLE opsMaturity: LOW | MEDIUM | HIGH timeToMarket: FAST | MEDIUM | SLOW }
ArchitectureRecommendation { pattern: MONOLITH | MICROSERVICES | EVENT_DRIVEN | SERVERLESS | HYBRID rationale: string tradeoffs: string migrationPath: string }
TechnologyScore { name: string fit: number // 1-5 maturity: number // 1-5 teamSkills: number // 1-5 performance: number // 1-5 operations:
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 6 files
plugins/team/skills/development/architecture-selection/SKILL.md
plugins/team/skills/development/architecture-selection/examples/adrs/001-example-adr.md
plugins/team/skills/development/architecture-selection/examples/architecture-patterns.md
plugins/team/skills/development/architecture-selection/reference/architecture-patterns.md
plugins/team/skills/development/architecture-selection/reference/c4-model.md
plugins/team/skills/development/architecture-selection/reference/scalability-and-reliability.md