Architecture Paradigms
Route a solo builder from vague system goals to the right architecture paradigm skill before committing to structure and ADRs.
Overview
Architecture Paradigms is an agent skill most often used in Validate (also Build, Ship) that selects and routes you to the right architecture paradigm skill before you commit to structure.
Install
npx skills add https://github.com/athola/claude-night-market --skill architecture-paradigmsWhat is this skill?
- Quick scenario router maps common situations to candidate paradigms
- 3-step selection workflow before delegating to a paradigm skill
- Routes to 13 dedicated architecture-paradigm dependency skills
- Supports paradigm-selection, architecture-review, implementation-planning, and ADR creation
- Exit criteria so you stop browsing patterns and pick a path
- 13 named architecture-paradigm dependency skills
- Estimated 280 tokens in skill metadata
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You know you need a sane architecture but drowning in pattern names makes it hard to pick one path and document the decision.
Who is it for?
Solo builders greenfielding a backend or API who want a checklist-driven paradigm pick instead of generic microservices advice.
Skip if: Teams that already locked an ADR and only need line-level refactors inside one chosen pattern—invoke a specific paradigm skill directly.
When should I use this skill?
Choosing patterns for a new system or comparing trade-offs before making architecture decisions.
What do I get? / Deliverables
You complete a short selection workflow with clear exit criteria and invoke the matching paradigm dependency skill to implement details and support ADR-style decisions.
- Selected paradigm recommendation with routing to the matching skill
- Documented exit criteria from the selection workflow
- Inputs for ADR or implementation-planning follow-up
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate/scope because trade-off comparison and paradigm choice happen while sizing the product and technical approach, before heavy implementation. Scope is where you decide what you are building and how big the architecture bet is—this router is meant to run there first, not after code is already entangled.
Where it fits
Compare event-driven vs layered options before you estimate build time for v1.
Lock a modular monolith boundary plan before the agent scaffolds packages and APIs.
Re-run the router when launch traffic assumptions invalidate your original paradigm choice.
Pick a pipeline or serverless paradigm for a throwaway prototype without overbuilding ops.
How it compares
Use as a structured router across paradigm skills, not as a single-pattern implementation guide or an MCP server.
Common Questions / FAQ
Who is architecture-paradigms for?
Indie and solo builders using agentic coding workflows who must choose system structure early—monolith vs services, event-driven vs layered—without hiring an architect for every spike.
When should I use architecture-paradigms?
During Validate/scope when comparing trade-offs for a new product; during Build/backend when planning module boundaries; during Ship/review when reassessing whether the chosen paradigm still fits growth constraints.
Is architecture-paradigms safe to install?
It is documentation and routing logic with no built-in shell or network calls, but you should still review the Security Audits panel on this Prism page before trusting any third-party skill in your repo.
Workflow Chain
SKILL.md
READMESKILL.md - Architecture Paradigms
## Table of Contents - [Quick Scenario Router](#quick-scenario-router) - [3-Step Selection Workflow](#3-step-selection-workflow) - [Available Paradigm Skills](#available-paradigm-skills) - [Integration with Other Skills](#integration-with-other-skills) - [Exit Criteria](#exit-criteria) # Architecture Paradigm Router This skill helps you **select** the right architecture paradigm(s) for your system, then **routes** you to the specific paradigm skill for implementation details. ## Quick Scenario Router Match your needs to the recommended paradigm: | Your Scenario | Primary Paradigm | Load Skill | |---------------|------------------|------------| | **Enterprise app with multiple teams** | Microservices or Modular Monolith | `architecture-paradigm-microservices` or `architecture-paradigm-modular-monolith` | | **Complex business rules & testing** | Functional Core, Imperative Shell | `architecture-paradigm-functional-core` | | **Real-time/event processing** | Event-Driven Architecture | `architecture-paradigm-event-driven` | | **Legacy system modernization** | Hexagonal (Ports & Adapters) | `architecture-paradigm-hexagonal` | | **Cloud-native/bursty workloads** | Serverless | `architecture-paradigm-serverless` | | **ETL/data processing pipeline** | Pipeline Architecture | `architecture-paradigm-pipeline` | | **Simple CRUD app** | Layered Architecture | `architecture-paradigm-layered` | | **Command/query separation** | CQRS and Event Sourcing | `architecture-paradigm-cqrs-es` | ## 3-Step Selection Workflow ### Step 1: Define Your Needs **Primary Concerns** (select all that apply): - **Testability**: Isolate business logic → `functional-core` or `hexagonal` - **Team Autonomy**: Independent deployment → `microservices` or `modular-monolith` - **Infrastructure Flexibility**: Swap databases/frameworks → `hexagonal` - **Real-time Scaling**: Variable loads with events → `event-driven` or `space-based` - **Simplicity**: Maintainable without complexity → `layered` or `modular-monolith` - **Legacy Integration**: Work with existing systems → `hexagonal` or `microkernel` **System Context**: - **Team Size**: `< 5` → Layered/Functional Core | `5-15` → Modular Monolith | `15-50` → Microservices | `50+` → Microservices/Space-Based - **Domain Complexity**: `Simple` → Layered | `Moderate` → Hexagonal/Modular Monolith | `Complex` → Functional Core/CQRS | `Highly Complex` → Microservices/Event-Driven ### Step 2: Evaluate Paradigms Based on your needs from Step 1, review these options: **For Testability & Business Logic** - Load `architecture-paradigm-functional-core` - Isolates business logic from infrastructure - Load `architecture-paradigm-hexagonal` - Clear domain/infrastructure boundaries **For Team Autonomy** - Load `architecture-paradigm-microservices` - Independent deployment and scaling - Load `architecture-paradigm-modular-monolith` - Team autonomy without distributed complexity **For Infrastructure Flexibility** - Load `architecture-paradigm-hexagonal` -