architecture-patterns
tessl i github:sickn33/antigravity-awesome-skills --skill architecture-patternsImplement 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.
Review Score
67%
Validation Score
12/16
Implementation Score
57%
Activation Score
67%
Generated
Validation
Total
12/16Score
Passed| Criteria | Score |
|---|---|
metadata_version | 'metadata' field is not a dictionary |
license_field | 'license' field is missing |
body_examples | No examples detected (no code fences and no 'Example' wording) |
body_output_format | No obvious output/return/format terms detected; consider specifying expected outputs |
Implementation
Suggestions 3
Score
57%Overall Assessment
The skill is well-structured and concise, appropriately delegating detailed content to an external playbook. However, it severely lacks actionability—the instructions are too abstract to be useful without concrete examples, code patterns, or specific architectural decisions. The workflow also needs validation checkpoints for architecture migrations.
Suggestions
- Add concrete code examples showing at least one architecture pattern (e.g., a Clean Architecture folder structure with sample interfaces and implementations)
- Include specific validation steps in the workflow, such as 'Verify no circular dependencies with: <command>' or 'Run architecture tests to confirm layer boundaries'
- Provide a concrete example of domain boundary definition (e.g., 'User domain owns: User, UserRepository interface; Infrastructure owns: PostgresUserRepository implementation')
| Dimension | Score | Reasoning |
|---|---|---|
Conciseness | 3/3 | The content is lean and efficient, avoiding unnecessary explanations of what Clean Architecture or DDD are. Every section serves a purpose without padding or concepts Claude already knows. |
Actionability | 1/3 | The instructions are vague and abstract ('Clarify domain boundaries', 'Select an architecture pattern') with no concrete code examples, specific commands, or executable guidance. It describes what to do rather than showing how. |
Workflow Clarity | 2/3 | Steps are listed in sequence but lack validation checkpoints or feedback loops. For architecture work involving potentially destructive refactoring, there's no explicit validation between steps or error recovery guidance. |
Progressive Disclosure | 3/3 | Clear overview structure with appropriate delegation to a single external resource (implementation-playbook.md). References are one level deep and clearly signaled. |
Activation
Suggestions 2
Score
67%Overall Assessment
This description has good structure with explicit 'what' and 'when' clauses, and names specific architecture patterns. However, it lacks concrete action verbs describing deliverables and misses common trigger term variations that users might naturally use when seeking architecture guidance.
Suggestions
- Add more concrete actions like 'define bounded contexts', 'create layer boundaries', 'structure dependency injection', 'separate domain from infrastructure'
- Include common trigger term variations: 'DDD', 'ports and adapters', 'onion architecture', 'code organization', 'separation of concerns', 'layered architecture'
| Dimension | Score | Reasoning |
|---|---|---|
Specificity | 2/3 | 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 specific deliverables like 'create layer boundaries', 'define domain models', or 'structure dependency injection'. |
Completeness | 3/3 | Clearly answers both what ('Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design') and when ('Use when architecting complex backend systems or refactoring existing applications for better maintainability') with explicit trigger guidance. |
Trigger Term Quality | 2/3 | Includes some relevant terms like 'Clean Architecture', 'Hexagonal Architecture', 'Domain-Driven Design', 'backend systems', and 'refactoring', but misses common variations users might say like 'ports and adapters', 'onion architecture', 'DDD', 'layered architecture', 'separation of concerns', or 'code organization'. |
Distinctiveness Conflict Risk | 2/3 | Reasonably specific to architecture patterns, but 'backend systems' and 'refactoring' are broad terms that could overlap with general coding skills or other backend-focused skills. The specific pattern names help distinguish it, but the scope could still conflict with general software design skills. |