Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use this skill when designing clean architecture for a new microservice, when refactoring a monolith to use bounded contexts, when implementing hexagonal or onion architecture patterns, or when debugging dependency cycles between application layers.
80
75%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/backend-development/skills/architecture-patterns/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly articulates specific architectural patterns and provides explicit trigger scenarios. It uses domain-appropriate terminology that developers would naturally use, and the 'Use this skill when...' clause covers four distinct use cases. The description is well-structured, concise, and uses proper third-person voice throughout.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete patterns: Clean Architecture, Hexagonal Architecture, Domain-Driven Design, and specific actions like designing microservices, refactoring monoliths, implementing onion architecture, and debugging dependency cycles. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement Clean Architecture, Hexagonal Architecture, DDD patterns) and 'when' with an explicit 'Use this skill when...' clause listing four specific trigger scenarios. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'clean architecture', 'microservice', 'monolith', 'bounded contexts', 'hexagonal', 'onion architecture', 'dependency cycles', 'application layers'. These cover common variations of how developers discuss backend architecture. | 3 / 3 |
Distinctiveness Conflict Risk | Targets a clear niche of backend architecture patterns with distinct terminology (bounded contexts, hexagonal architecture, onion architecture, dependency cycles between layers) that is unlikely to conflict with general coding or frontend skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides excellent, executable code examples covering Clean Architecture, Hexagonal Architecture, and DDD patterns, making it highly actionable. However, it is significantly over-verbose, spending many tokens explaining architectural concepts Claude already understands (layer definitions, DDD terminology, benefits lists). The content would benefit greatly from cutting the explanatory prose and restructuring as a lean overview with references to detailed implementation files.
Suggestions
Remove the 'Core Concepts' section entirely or reduce it to a 2-3 line summary per pattern — Claude already knows what Clean Architecture, Hexagonal Architecture, and DDD are. Focus only on project-specific conventions and decisions.
Add an explicit step-by-step workflow for architecting a new service (e.g., '1. Identify bounded context → 2. Define domain entities → 3. Define ports → 4. Implement use cases → 5. Verify: no imports from adapters/ in domain/ or use_cases/ → 6. Implement adapters'), with a validation checkpoint for dependency rule compliance.
Move the full code implementations (Clean Architecture core, Hexagonal example, DDD aggregates, testing) into separate reference files and keep only a minimal example in the main SKILL.md with links to the detailed files.
Remove bullet lists that describe benefits or 'when to use' — these are generic knowledge. Replace with a single sentence like 'Use when establishing layered architecture for a backend service.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~400+ lines, explaining concepts Claude already knows well (Clean Architecture layers, DDD strategic/tactical patterns, hexagonal architecture benefits). Sections like 'Core Concepts' are textbook summaries that add no novel information for Claude. The 'When to Use This Skill' and 'Benefits' lists are padding. | 1 / 3 |
Actionability | The code examples are fully executable Python with complete implementations across all layers — entities, interfaces, use cases, adapters, controllers, and tests. The directory structure, import rules, and test patterns are concrete and copy-paste ready. | 3 / 3 |
Workflow Clarity | While the content shows what each layer looks like, there's no clear step-by-step workflow for actually architecting a new service (e.g., 'Step 1: Define domain entities, Step 2: Define ports, Step 3: Implement use cases...'). The troubleshooting section helps but there are no validation checkpoints for verifying dependency rules are followed correctly. | 2 / 3 |
Progressive Disclosure | There is a reference to 'references/advanced-patterns.md' and related skills at the end, which is good. However, the main file is monolithic with extensive inline code that could be split — the full implementation examples, hexagonal patterns, DDD patterns, and testing could each be separate reference files, with the SKILL.md serving as a concise overview. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
70444e5
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.