jbvc/architecture-patterns
Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use when architecting complex backend systems or refactoring existing applications for better maintainability.
65
65%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has a solid structure with an explicit 'Use when' clause and names specific architecture patterns, which is good. However, it lacks concrete action verbs beyond 'implement' and 'refactoring', and could benefit from more natural trigger terms that users would actually say. The description is competent but could be more specific about what actions it performs and more distinctive in its trigger terms.
Suggestions
Add more specific concrete actions, e.g., 'define bounded contexts, create port/adapter interfaces, separate domain logic from infrastructure, structure project layers'.
Include common trigger term variations users might naturally use: 'DDD', 'ports and adapters', 'onion architecture', 'layered architecture', 'separation of concerns', 'dependency inversion'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (backend architecture) and lists specific patterns (Clean Architecture, Hexagonal Architecture, DDD), but doesn't describe concrete actions beyond 'implement' and 'refactoring'. Lacks specifics like 'define bounded contexts, create port/adapter interfaces, separate domain from infrastructure layers'. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement Clean Architecture, Hexagonal Architecture, and DDD patterns) and 'when' (when architecting complex backend systems or refactoring existing applications for better maintainability) with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'Clean Architecture', 'Hexagonal Architecture', 'Domain-Driven Design', 'backend systems', and 'refactoring'. However, it misses common user variations like 'ports and adapters', 'onion architecture', 'DDD', 'layered architecture', 'separation of concerns', or 'dependency inversion'. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on specific architecture patterns (Clean, Hexagonal, DDD) provides some distinctiveness, but 'backend architecture' and 'refactoring' are broad enough to potentially overlap with general backend development skills, code refactoring skills, or design pattern skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
22%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a thin wrapper that defers all substantive content to an external resource file. The body provides no concrete patterns, code examples, architectural templates, or specific guidance—just abstract meta-instructions. While the structure is reasonable, the lack of actionable content in the skill itself makes it nearly useless without the referenced playbook.
Suggestions
Add concrete, executable examples for at least one architecture pattern (e.g., a Clean Architecture folder structure with sample code showing dependency direction).
Replace the abstract 4-step instructions with specific, actionable steps including validation checkpoints (e.g., 'Verify no domain layer imports from infrastructure by running dependency analysis').
Include a quick-start section with a minimal but complete example—such as a Python or TypeScript project skeleton implementing hexagonal architecture—so Claude has actionable guidance even without the external resource.
Trim the 'Use this skill when' / 'Do not use this skill when' lists which add little value, and use that space for actual architectural guidance content.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Use this skill when' and 'Do not use this skill when' sections are somewhat verbose and explain things Claude could infer. The opening sentence restates the description. However, the instructions section itself is lean. | 2 / 3 |
Actionability | The instructions are entirely abstract ('Clarify domain boundaries', 'Select an architecture pattern') with no concrete code, commands, examples, or specific guidance. Everything actionable is deferred to an external resource file. | 1 / 3 |
Workflow Clarity | The four steps are vague and lack any validation checkpoints, concrete outputs, or feedback loops. 'Provide migration steps and validation checks' is meta-instruction rather than an actual workflow with explicit verification. | 1 / 3 |
Progressive Disclosure | There is a reference to an external resource file which is appropriate, but the SKILL.md itself provides almost no substantive overview content—it's essentially empty, delegating everything to the playbook without giving Claude enough to work with at the top level. | 2 / 3 |
Total | 6 / 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.
Reviewed
Table of Contents