Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-architectural-styles-tradeoffs
Architectural style selection decision matrices, trade-off analysis, structural enforcement rules, and combination patterns. Load when choosing or evaluating architecture styles.
Passed 22 of 22 test cases with the skill, and 13 of 22 without it.
and 6 more in the full report
9 fixed13 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are building a monolithic backend in Go where feature modules must maintain strict module boundaries and prevent circular imports. Which static analysis dependency linter specifically designed for Go should we use, and how should we annotate the design document?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends go-arch-lint as the Go architecture enforcement tool. | Passed | Passed |
| Includes a markdown block with header ## Architecture Enforcement containing Style, Language, Tool, and Rules to enforce. | Missed | Passed |
The instructions your model reads when the skill loads.
Start here. Answer the dominant driver, follow to recommended style.
Is the domain complex with rich business rules?
YES -> Do you need infrastructure independence and high testability?
YES -> Hexagonal / Clean / Onion (functionally equivalent, different terminology)
NO -> Is the domain well-understood with clear module boundaries?
YES -> Modular Monolith (single deployment, structured boundaries)
NO -> Layered Architecture (simple, well-known, fast to start)
NO -> Is this a feature-heavy application with independent feature teams?
YES -> Vertical Slice (per-feature organization, CQRS-friendly)
NO -> Do you need independent deployment and scaling per capability?
YES -> Can the team handle distributed system operational complexity?
YES -> Microservices
NO -> Modular Monolith (extract to services later)
NO -> Is the primary concern async workflows or event-driven processing?
YES -> Event-Driven Architecture
NO -> Is this a data processing pipeline?
YES -> Pipe and Filter
NO -> Layered Architecture (sensible default)
| Style | Dep. Direction | Organization | Deployment | Best For | Team Size |
|---|---|---|---|---|---|
| Hexagonal/Clean/Onion | Inward (DIP) | Ports + adapters | Single process | Infrastructure-agnostic domains | Any |
| Layered (N-Tier) | Top-down | Horizontal layers | Single/multi-tier | Simple CRUD, rapid development | Small-medium |
| Vertical Slice | Per-feature | Feature folders | Single process | Feature-heavy, CQRS systems | Medium-large |
| Microservices | Per-service | Service boundaries | Distributed | Independent teams, polyglot | Large |
| Event-Driven | Pub-sub | Events + handlers | Distributed | Async workflows, audit, decoupling | Medium-large |
| CQRS | Read/write split | Command + query models | Single or distributed | Different read/write scaling | Medium |
| Pipe and Filter | Data flow | Sequential filters | Single or distributed | ETL, data processing | Any |
| Modular Monolith | Inward per module | Domain modules | Single process | Structured monolith, future extraction | Small-medium |
test cases passed, vs 13 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.