Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →wondelai/clean-architecture
Structure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities.
Passed 24 of 24 test cases with the skill, and 21 of 24 without it.
3 fixed21 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
I need an architectural review of our payment service. Currently, our API controllers handle HTTP requests, instantiate TypeORM repositories directly, and contain some of our discount calculation logic. Can you evaluate our current setup against clean architecture principles? Please report our architecture score, list all the diagnostic rows that failed, and detail the specific inversions needed to fix every issue.
| Checked | Without skill | With skill |
|---|---|---|
| Provides an architecture score on the 0-10 scale derived from evaluating the 7 quick diagnostic questions. | Missed | Passed |
| Identifies failing diagnostic criteria for framework and database coupling. | Passed | Passed |
| Explains extracting repository interfaces to decouple database access from controllers. | Passed | Passed |
The instructions your model reads when the skill loads.
A disciplined approach to structuring software so that business rules remain independent of frameworks, databases, and delivery mechanisms. Apply these principles when designing system architecture, reviewing module boundaries, or advising on dependency management.
Source code dependencies must point inward — toward higher-level policies. Nothing in an inner circle can know anything about an outer circle. This single rule produces systems that are testable and independent of frameworks, UI, database, and any external agency. Business rules are what matter; databases, web frameworks, and delivery mechanisms are details — when details depend on policies, you can defer decisions, swap implementations, and test business logic in isolation.
Goal: 10/10. Score one point for each of the seven Quick Diagnostic rows the architecture satisfies (0-7), then map to a 0-10 band: 6-7 satisfied = 9-10 (Dependency Rule holds, business logic is framework- and DB-independent); 4-5 = 6-8 (core is testable but some details leak inward); 2-3 = 3-5 (framework or persistence dictates structure); 0-1 = 0-2 (no boundaries — business rules live in controllers and ORM models). Report the score, the failed diagnostic rows, and the specific inversion needed to fix each.
Core concept: Organize the architecture as concentric circles — Entities (enterprise business rules) innermost, then Use Cases (application business rules), then Interface Adapters, with Frameworks and Drivers outermost. Source code dependencies always point inward.
Why it works: When high-level policies don't depend on low-level details, you can swap the database, web framework, or API style without touching business logic — the system becomes resilient to the most volatile parts of the stack.
Key insights:
Code applications:
| Context | Pattern | Example |
|---|---|---|
| Layer direction | Inner circles define interfaces; outer implement | UserRepository interface in Use Cases; PostgresUserRepository in Adapters |
| Data crossing | DTOs cross boundaries, not ORM entities | Use Case returns UserResponse DTO, not an ActiveRecord model |
| Dependency direction | Import arrows always point inward | Controller imports Use Case; Use Case never imports Controller |
See references/dependency-rule.md when an inner-circle import points outward and you need the four-circle code walkthrough, the data-crossing rules, and the four-step dependency-inversion procedure to fix it.
Core concept: Entities encapsulate enterprise-wide business rules — rules that would exist even without software. Use Cases contain application-specific rules that orchestrate the flow of data to and from Entities.
Why it works: Separating what the business does (Entities) from how the application orchestrates it (Use Cases) lets you reuse Entities across applications and change application behavior without altering core business rules.
test cases passed, vs 21 / 24 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.