architecture-patterns

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.

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/backend-development/skills/architecture-patterns/SKILL.md

Quality

Content

61%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

Well-structured content with genuinely executable examples and specific troubleshooting guidance, held back by a Core Concepts section that re-teaches widely known architecture theory and the absence of an explicit sequenced workflow. References are real and well-signaled.

Suggestions

Cut the 'Core Concepts' section down to a terse layer/component map (or move it to references/details.md) — the textbook definitions of Clean Architecture, Hexagonal, and DDD tactical patterns are knowledge Claude already has.

Add a short ordered design workflow (e.g., 1. identify bounded contexts, 2. define entities/value objects, 3. define ports, 4. pick adapters, 5. verify with in-memory tests) so the concepts assemble into a sequence with an explicit validation checkpoint.

Drop the intro sentence that restates the frontmatter description, and consider pointing to the reference directory tree from the main body so scaffolding guidance is discoverable without loading references.

Dimension	Reasoning	Score
Conciseness	The ~45-line 'Core Concepts' section re-explains textbook Clean/Hex/DDD definitions (e.g., 'Dependencies point inward only', 'Value Objects: Immutable objects identified by their attributes') that Claude already knows, and the intro line duplicates the description — noticeable but not pervasive padding, so above the verbose anchors yet short of efficient.	3 / 5
Actionability	The in-memory repository test is complete, executable Python, and troubleshooting entries give concrete fixes ('Validate invariants in __post_init__', 'map to/from the domain entity in the repository's _to_entity() method'). Directory scaffolding lives only in references and some guidance stays directional, leaving minor gaps.	4 / 5
Workflow Clarity	The body is organized by concept rather than as a sequenced design workflow; the in-memory test section and symptom→fix troubleshooting provide implicit validation checkpoints, but no explicit ordered process with checkpoints is stated. This is a design skill, so the destructive/batch cap does not apply.	3 / 5
Progressive Disclosure	Both references ('references/details.md', 'references/advanced-patterns.md') exist, are clearly signaled ('Read that file when the navigation tier above is insufficient'), and are one level deep with no nesting. The inline Core Concepts and long code example could be trimmed or moved to references, fitting the 'minor organization gaps' anchor.	4 / 5
	Total	14 / 20 Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description that clearly states capabilities and provides explicit, concrete 'use when' triggers. Minor improvements possible by enumerating what the skill actually produces and adding common synonyms like 'ports and adapters'.

Dimension	Reasoning	Score
Specificity	The description names the domain and three concrete patterns ('Clean Architecture, Hexagonal Architecture, and Domain-Driven Design') but the action verb stays generic ('Implement') and does not enumerate concrete deliverables, matching the 'several specific actions with minor gaps' anchor rather than comprehensive coverage.	4 / 5
Completeness	It explicitly answers both 'what' ('Implement proven backend architecture patterns including...') and 'when' with a clear 'Use this skill when...' clause listing four concrete trigger scenarios, matching the top anchor.	5 / 5
Trigger Term Quality	Phrases like 'refactoring a monolith to use bounded contexts', 'hexagonal or onion architecture patterns', and 'debugging dependency cycles' are natural user phrasing with good coverage, but common synonyms such as 'ports and adapters' or 'layered architecture' are absent, so it falls just short of the comprehensive anchor.	4 / 5
Distinctiveness Conflict Risk	The niche (backend architecture patterns with named styles and dependency-cycle debugging) is distinct, but triggers like 'designing clean architecture for a new microservice' carry minor overlap risk with closely related skills such as microservices decomposition, fitting the 'mostly distinct' anchor.	4 / 5
	Total	17 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: wshobson/agents
Path: plugins/backend-development/skills/architecture-patterns/SKILL.md
Commit: 156b7a5

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

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.