How do I install the Architecture skill?

Run npx skillmds@latest add managedcode/architecture in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Architecture safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Architecture?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Architecture free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Architecture?

managedcode (@managedcode) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Architecture by managedcode — Agent Skill

Name: Architecture
Author: managedcode

Architecture

Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering. USE FOR: .NET architecture choices; layer and domain boundary review; service decomposition; clean architecture, vertical slice, DDD, CQRS, and modular monolith decisions. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.

managedcode e3596de 4 files · 45.5 KB Updated Sep 17, 2026

File contents

.NET Architecture

Trigger On

choosing architecture for a new or evolving .NET system
reviewing layer boundaries, domain boundaries, or service decomposition
deciding whether clean architecture, vertical slices, CQRS, or microservices are justified

Workflow

Start from business capability boundaries and change frequency, not from a preferred diagram style.
Use simple modular monolith patterns by default, and move to microservices only when team autonomy, scale, or deployment boundaries justify the added operational cost.
Apply DDD and CQRS where business rules are genuinely complex; avoid forcing aggregates and command pipelines into CRUD-heavy code with no payoff.
Keep dependencies flowing inward when using clean architecture, but avoid creating extra projects that add ceremony without ownership clarity.
Make integration boundaries explicit: contracts, storage ownership, messaging, consistency model, and observability expectations.
Use aspire when local orchestration, service discovery, and developer observability are part of the architecture story.

Deliver

an architecture direction that matches system complexity
clear project and dependency boundaries
migration notes or tradeoffs when changing an existing structure

Validate

the proposed structure reduces rather than increases accidental complexity
data ownership and integration paths are explicit
the architecture is testable and operable, not just diagram-friendly

References

references/patterns.md - detailed implementations of Clean Architecture, Vertical Slices, DDD, CQRS, Modular Monolith, and Microservices with C# 12+ examples
references/anti-patterns.md - common architectural mistakes including over-abstraction, anemic domain models, premature microservices, and cargo cult patterns

---name: architecturedescription: Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering. USE FOR: .NET architecture choices; layer and domain boundary review; service decomposition; clean architecture, vertical slice, DDD, CQRS, and modular monolith decisions. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.---# .NET Architecture## Trigger On- choosing architecture for a new or evolving .NET system- reviewing layer boundaries, domain boundaries, or service decomposition- deciding whether clean architecture, vertical slices, CQRS, or microservices are justified## Workflow1. Start from business capability boundaries and change frequency, not from a preferred diagram style.2. Use simple modular monolith patterns by default, and move to microservices only when team autonomy, scale, or deployment boundaries justify the added operational cost.3. Apply DDD and CQRS where business rules are genuinely complex; avoid forcing aggregates and command pipelines into CRUD-heavy code with no payoff.4. Keep dependencies flowing inward when using clean architecture, but avoid creating extra projects that add ceremony without ownership clarity.5. Make integration boundaries explicit: contracts, storage ownership, messaging, consistency model, and observability expectations.6. Use `aspire` when local orchestration, service discovery, and developer observability are part of the architecture story.## Deliver- an architecture direction that matches system complexity- clear project and dependency boundaries- migration notes or tradeoffs when changing an existing structure## Validate- the proposed structure reduces rather than increases accidental complexity- data ownership and integration paths are explicit- the architecture is testable and operable, not just diagram-friendly## References- [references/patterns.md](references/patterns.md) - detailed implementations of Clean Architecture, Vertical Slices, DDD, CQRS, Modular Monolith, and Microservices with C# 12+ examples- [references/anti-patterns.md](references/anti-patterns.md) - common architectural mistakes including over-abstraction, anemic domain models, premature microservices, and cargo cult patterns

Frequently asked questions