Clean Architecture
Apply Robert C. Martin Clean Architecture rules when designing modules, reviewing dependency direction, or refactoring coupled code toward testable boundaries.
Overview
clean-architecture is an agent skill most often used in Build (also Ship review) that applies 42 Clean Architecture rules for layers, boundaries, and dependency direction.
Install
npx skills add https://github.com/pproenca/dot-skills --skill clean-architectureWhat is this skill?
- 42 prioritized rules across 8 architectural categories
- Critical focus on dependency direction and entity design prefixes (dep-, entity-)
- Use-case isolation and component cohesion at HIGH priority
- Triggers on layers, boundaries, entities, use cases, and refactoring coupled systems
- Grounded in Clean Architecture: A Craftsman's Guide to Software Structure and Design
- 42 rules across 8 categories
- 8 rule categories from Dependency Direction through Testing Architecture
Adoption & trust: 1.6k installs on skills.sh; 157 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your app mixes frameworks, UI, and business rules so tests are brittle and every feature tears through unrelated layers.
Who is it for?
Indie builders designing APIs, agents, or SaaS backends who want an agent to sanity-check structure against Uncle Bob’s layer model.
Skip if: One-off scripts, throwaway prototypes, or front-end-only tweaks with no layered domain model.
When should I use this skill?
Tasks involving layers, boundaries, dependency direction, entities, use cases, system architecture, or refactoring toward separation of concerns.
What do I get? / Deliverables
You align new and existing code with inward dependencies, clear entities and use cases, and explicit boundaries you can enforce in review.
- Architecture recommendations mapped to dep-, entity-, and usecase- rule categories
- Refactor or review notes identifying boundary and framework isolation violations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
First meaningful use is Build when you shape layers, entities, and use cases before the codebase hardens—though the same rules apply later in review. Backend subphase fits dependency-inward design, use-case isolation, and framework boundaries typical of application cores and APIs.
Where it fits
Define entity and use-case packages before wiring Postgres and HTTP adapters.
Flag a PR that imports ORM models directly into domain entities.
Plan a strangler refactor that moves framework code behind interface adapters.
How it compares
Architecture rule pack for structure and dependencies—not a linter config or framework scaffold generator.
Common Questions / FAQ
Who is clean-architecture for?
Developers shipping maintainable backends or full-stack products who want Clean Architecture principles applied during design, refactor, and architectural code review.
When should I use clean-architecture?
Use it in Build when designing modules and dependency graphs, in Ship during review when infrastructure bleeds into entities, and in Operate when iterating on legacy services that need safer boundaries.
Is clean-architecture safe to install?
It is documentation-style guidance without built-in shell side effects; confirm trust via the Security Audits panel on this Prism page before adding to your agent workflow.
SKILL.md
READMESKILL.md - Clean Architecture
# Clean Architecture Best Practices Comprehensive guide to Clean Architecture principles for designing maintainable, testable software systems. Based on Robert C. Martin's "Clean Architecture: A Craftsman's Guide to Software Structure and Design." Contains 42 rules across 8 categories, prioritized by architectural impact. ## When to Apply Reference these guidelines when: - Designing new software systems or modules - Structuring dependencies between layers - Defining boundaries between business logic and infrastructure - Reviewing code for architectural violations - Refactoring coupled systems toward cleaner structure ## Rule Categories by Priority | Priority | Category | Impact | Prefix | |----------|----------|--------|--------| | 1 | Dependency Direction | CRITICAL | `dep-` | | 2 | Entity Design | CRITICAL | `entity-` | | 3 | Use Case Isolation | HIGH | `usecase-` | | 4 | Component Cohesion | HIGH | `comp-` | | 5 | Boundary Definition | MEDIUM-HIGH | `bound-` | | 6 | Interface Adapters | MEDIUM | `adapt-` | | 7 | Framework Isolation | MEDIUM | `frame-` | | 8 | Testing Architecture | LOW-MEDIUM | `test-` | ## Quick Reference ### 1. Dependency Direction (CRITICAL) - [`dep-inward-only`](references/dep-inward-only.md) - Source dependencies point inward only - [`dep-interface-ownership`](references/dep-interface-ownership.md) - Interfaces belong to clients not implementers - [`dep-no-framework-imports`](references/dep-no-framework-imports.md) - Avoid framework imports in inner layers - [`dep-data-crossing-boundaries`](references/dep-data-crossing-boundaries.md) - Use simple data structures across boundaries - [`dep-acyclic-dependencies`](references/dep-acyclic-dependencies.md) - Eliminate cyclic dependencies between components - [`dep-stable-abstractions`](references/dep-stable-abstractions.md) - Depend on stable abstractions not volatile concretions ### 2. Entity Design (CRITICAL) - [`entity-pure-business-rules`](references/entity-pure-business-rules.md) - Entities contain only enterprise business rules - [`entity-no-persistence-awareness`](references/entity-no-persistence-awareness.md) - Entities must not know how they are persisted - [`entity-encapsulate-invariants`](references/entity-encapsulate-invariants.md) - Encapsulate business invariants within entities - [`entity-value-objects`](references/entity-value-objects.md) - Use value objects for domain concepts - [`entity-rich-not-anemic`](references/entity-rich-not-anemic.md) - Build rich domain models not anemic data structures ### 3. Use Case Isolation (HIGH) - [`usecase-single-responsibility`](references/usecase-single-responsibility.md) - Each use case has one reason to change - [`usecase-input-output-ports`](references/usecase-input-output-ports.md) - Define input and output ports for use cases - [`usecase-orchestrates-not-implements`](references/usecase-orchestrates-not-implements.md) - Use cases orchestrate entities not implement business rules - [`usecase-no-presentation-logic`](references/usecase-no-presentation-logic.md) - Use cases must not contain presentation logic - [`usecase-explicit-dependencies`](references/usecase-explicit-dependencies.md) - Declare all dependencies explicitly in constructor - [`usecase-transaction-boundary`](references/usecase-transaction-boundary.md) - Use case defines the transaction boundary ### 4. Component Cohesion (HIGH) - [`comp-screaming-architecture`](references/comp-screaming-architecture.md) - Structure should scream the domain not the framework - [`comp-common-closure`](references/comp-common-closure.md) - Group classes that c