architecture-patterns

Master proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design to build maintainable, testable, and scalable systems.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

35%

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

The body is well-structured and concise, but its instructions are abstract rather than actionable, the workflow lacks validation checkpoints, and its sole progressive-disclosure reference points to a file that is not present in the bundle.

Suggestions

Make the instructions concrete and executable: name the architecture patterns with their selection criteria, and add a sample module-boundary or dependency-rule snippet instead of generic directives like 'Define module boundaries'.

Add validation checkpoints to the workflow (e.g., verify dependency direction against the chosen pattern before migrating) so multi-step design work has explicit feedback loops.

Either provide the referenced `resources/implementation-playbook.md` bundle file or remove the dangling reference so progressive disclosure resolves to real content.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean with organized sections and no explanation of concepts Claude already knows, but the intro repeats the frontmatter description verbatim and `resources/implementation-playbook.md` is referenced twice (Instructions and Resources), with step 5's DBOS note being mildly padded, fitting the 'mostly efficient but could be tightened' anchor.	2 / 3
Actionability	Instructions like 'Clarify domain boundaries', 'Select an architecture pattern that fits', and 'Define module boundaries' are abstract directives with no concrete code, commands, selection criteria, or artifacts; this matches the 'vague or abstract; describes rather than instructs' anchor and is not rescued by the instruction-only guidance because the steps are not specific.	1 / 3
Workflow Clarity	A clear five-step sequence exists (clarify -> select -> define -> migrate -> durable execution), but there are no validation checkpoints or feedback loops, matching the 'steps listed but validation gaps; checkpoints missing or implicit' anchor rather than the validated-workflow anchor above.	2 / 3
Progressive Disclosure	Sections are well-organized and the single reference `resources/implementation-playbook.md` is clearly signaled and one level deep, but the referenced file does not exist in the bundle, so per the bundle-structure guideline the navigation does not resolve, matching the 'some structure but could be better organized' anchor rather than the clean one-level reference anchor.	2 / 3
	Total	7 / 12 Passed

Description

57%

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 identifies a clear niche with specific named patterns but stops short of listing concrete actions or providing an explicit 'Use when...' trigger, leaving the 'when to use' guidance only implied.

Suggestions

Add an explicit 'Use when...' clause naming natural triggers (e.g., designing new backend systems, refactoring a monolith, adopting DDD) so the description answers 'when' as well as 'what'.

Replace the abstract 'to build maintainable, testable, and scalable systems' with concrete verbs a user would say (e.g., 'Design, refactor, and decompose backend systems') to lift specificity.

Include common keyword variations users might actually say (e.g., 'microservices', 'layered architecture', 'dependency inversion') to broaden trigger coverage.

Dimension	Reasoning	Score
Specificity	Quotes 'Master proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design' name the domain and specific patterns, but 'to build maintainable, testable, and scalable systems' is an abstract capability claim rather than a list of concrete actions, matching the 'names domain and some actions, but not comprehensive' anchor.	2 / 3
Completeness	It clearly answers 'what' (master backend architecture patterns), but provides no explicit 'when' trigger guidance; per the judging guidelines a missing 'Use when...' clause caps completeness at 2, matching the 'has what, but when is missing or only implied' anchor.	2 / 3
Trigger Term Quality	Terms like 'backend architecture', 'Clean Architecture', 'Hexagonal Architecture', and 'Domain-Driven Design' are relevant keywords, but the description lacks common natural variations and has no 'Use when...' trigger phrase, fitting the 'some relevant keywords but missing common variations' anchor.	2 / 3
Distinctiveness Conflict Risk	The named patterns (Clean Architecture, Hexagonal Architecture, Domain-Driven Design) carve out a clear niche unlikely to trigger for unrelated skills, matching the 'clear niche with distinct triggers; unlikely to conflict' anchor rather than the overlapping-skill anchor below it.	3 / 3
	Total	9 / 12 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: boisenoise/skills-collections
Commit: f36337d

Reviewed: 2 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.