System Architect
Ground architecture choices—monolith vs modular monolith, NFRs, and stack trade-offs—before your agent implements features.
Overview
System Architect is an agent skill most often used in Validate (also Build, Ship) that supplies architectural patterns, NFR mapping, and trade-off frameworks for solo builders choosing system shape before implementation.
Install
npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill system-architectWhat is this skill?
- Reference for monolith, modular monolith, and related application architecture patterns with when-to-use criteria
- Pattern selection criteria and NFR mapping reference for non-functional requirements
- Technology stack selection and structured trade-off analysis framework
- Component design principles for maintainable boundaries
- Level 0–1 team guidance (e.g. 1–3 developers, MVPs, internal tools)
- Documents multiple named architectural patterns (e.g. monolith, modular monolith) with selection criteria
- Table of contents spans 6 reference sections including NFR mapping and trade-off analysis
Adoption & trust: 566 installs on skills.sh; 443 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to build but lack a shared, explicit view of architecture patterns, NFRs, and stack trade-offs for a small team or MVP.
Who is it for?
Solo builders scoping a SaaS, API, or mobile-backed product who want BMAD-aligned architecture reference before committing to a monolith or modular layout.
Skip if: Teams that already have an approved architecture decision record and only need line-level coding in a fixed stack.
When should I use this skill?
You need architectural pattern reference, NFR mapping, stack selection, or trade-off analysis before or during technical design.
What do I get? / Deliverables
You get a decision-ready framing—pattern fit, NFR mapping, and stack trade-offs—that can feed specs, plans, and implementation tasks without guessing structure mid-build.
- Architecture pattern recommendation grounded in documented criteria
- NFR-to-architecture mapping notes
- Documented stack trade-offs for the agent or spec
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate/scope because system shape and NFR mapping belong with scoping and technical feasibility, before heavy Build work. Scope subphase is where solo builders lock deployment model, coupling boundaries, and technology bets that downstream implementation must honor.
Where it fits
Compare monolith vs modular monolith before writing the implementation plan for a three-person SaaS MVP.
Define module boundaries and in-process vs service boundaries while splitting features.
Revisit NFR mapping when launch traffic and latency goals tighten deployment choices.
Pick the simplest pattern for a proof-of-concept without over-engineering microservices.
How it compares
Use as structured architecture reference during scoping, not as a deploy script or a single-feature integration skill.
Common Questions / FAQ
Who is system-architect for?
Indie and solo builders using Claude Code or similar agents who need architectural patterns and NFR guidance during scoping and early technical design, especially on small-team MVPs.
When should I use system-architect?
During Validate when narrowing scope and stack; during Build when splitting modules or APIs; and during Ship when aligning NFRs with launch and performance constraints.
Is system-architect safe to install?
It is primarily reference documentation with no mandated shell or network hooks in the excerpt; review the Security Audits panel on this Prism page before installing from any third-party skills repo.
SKILL.md
READMESKILL.md - System Architect
# System Architect Reference This document provides detailed reference material for architectural patterns, NFR mapping, and decision-making frameworks. ## Table of Contents 1. [Architectural Patterns](#architectural-patterns) 2. [Pattern Selection Criteria](#pattern-selection-criteria) 3. [NFR Mapping Reference](#nfr-mapping-reference) 4. [Technology Stack Selection](#technology-stack-selection) 5. [Trade-off Analysis Framework](#trade-off-analysis-framework) 6. [Component Design Principles](#component-design-principles) --- ## Architectural Patterns ### Application Architecture Patterns #### 1. Monolith **Description:** Single deployable unit containing all application functionality. **Characteristics:** - All code in one codebase - Single deployment artifact - Shared database - In-process communication **When to Use:** - Level 0-1 projects - Small teams (1-3 developers) - Simple requirements - Rapid prototyping - MVPs and proofs of concept **Pros:** - Simple to develop and deploy - Easy to test end-to-end - No network latency between components - Simple data consistency **Cons:** - Scales as a unit (all or nothing) - Can become complex over time - Tight coupling risk - Limited technology choices **Example Use Cases:** - Internal tools - Simple CRUD applications - Company websites - Small SaaS products --- #### 2. Modular Monolith **Description:** Monolith organized into well-defined modules with clear boundaries. **Characteristics:** - Logical separation into modules - Single deployment - Module-level encapsulation - Shared database with module-specific schemas - Can evolve to microservices **When to Use:** - Level 2 projects - Medium teams (4-8 developers) - Growing complexity - Need for module independence - Future microservices potential **Pros:** - Balance of simplicity and modularity - Team can work on different modules - Refactoring to microservices easier - Still simple deployment **Cons:** - Requires discipline to maintain boundaries - Can still have coupling issues - Shared database coordination needed **Example Use Cases:** - E-commerce platforms - SaaS applications - Enterprise applications - Multi-tenant systems --- #### 3. Microservices **Description:** Independent services communicating via APIs, each deployable separately. **Characteristics:** - Multiple services with independent lifecycles - Service-specific databases - API-based communication - Independent scaling - Polyglot programming possible **When to Use:** - Level 3-4 projects - Large teams (10+ developers) - Complex domains - High scalability needs - Multiple team independence required **Pros:** - Independent scaling per service - Technology diversity - Team autonomy - Isolated failures - Easier to understand individual services **Cons:** - Operational complexity - Network latency - Distributed data challenges - Testing complexity - Requires DevOps maturity **Example Use Cases:** - Large-scale SaaS platforms - High-traffic applications - Complex business domains - Global distributed systems --- #### 4. Serverless **Description:** Event-driven functions managed by cloud provider, no server management. **Characteristics:** - Function-as-a-Service (FaaS) - Event-driven execution - Automatic scaling - Pay-per-execution - Stateless functions **When to Use:** - Event-driven workloads - Irregular traffic patterns - Background processing - API backends - Cost optimization priority **Pros:** - Zero server management - Automatic scaling - Pay only for execution - Fast deployment **Cons:** - Cold start latency - Vendor lock-in - Limited execution time - Debugging challenges - Complex orchestration **Example Use Cases:** - API gateways - Background jobs - Image processing - IoT data processing - Scheduled tasks --- #### 5. Layered Architecture **Description:** Traditional separation into presentation, business logic, and data layers. **Characteristics:** - Clear layer separation - Top-down dependencies - Each layer has sp