architecture-patterns

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

Quality

51%

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 ./skills/antigravity-architecture-patterns/SKILL.md

Quality

Content

42%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.

The body has a clean, terse structure with good scope boundary sections, but delivers almost no actionable content: instructions are abstract directives and the only detail resource is a missing file. It currently functions as an outline of a skill rather than a usable skill. Fixing the dangling reference and inlining concrete selection criteria or dependency-rule examples would address the weakest dimensions.

Suggestions

Fix the dangling reference: either add `resources/implementation-playbook.md` to the bundle or inline the key content (pattern-selection criteria, dependency rules, migration checklists) directly into SKILL.md.

Make the instructions concrete and executable — e.g. name the decision criteria for choosing Clean vs. Hexagonal vs. DDD, show an example dependency-rule enforcement (import-linter config or module boundary diagram), and give a concrete migration step sequence.

Remove redundancy: drop the verbatim restatement of the description as the intro and consolidate the duplicate "Refer to resources/implementation-playbook.md" line into the single Resources section.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean and free of concept explanations Claude already knows, but it repeats the frontmatter description verbatim as the intro, states "Refer to `resources/implementation-playbook.md` for detailed patterns, checklists, and templates" twice (in Instructions and again in Resources), and carries boilerplate Limitations lines. This fits anchor 3 ("could be tightened") better than anchor 4's "minor instances".	3 / 5
Actionability	The instructions are high-level directives — "Select an architecture pattern that fits the domain complexity", "Define module boundaries, interfaces, and dependency rules" — with no concrete criteria, examples, commands, or decision guidance, and the playbook that supposedly holds the details does not exist. This matches anchor 2 (high-level hints missing the specific steps to execute); not 3 because there is no concrete, executable guidance anywhere in the body.	2 / 5
Workflow Clarity	A five-step sequence is present (clarify → select → define → provide migration steps → apply durable execution), but validation is only prescribed as an output ("Provide... validation checks") rather than performed as a checkpoint, and there are no feedback loops. Not 4 because checkpoints are missing entirely rather than having minor gaps; not 2 because the sequence itself is coherent and well-ordered.	3 / 5
Progressive Disclosure	The body is short and well-sectioned (Use when / Do not use when / Instructions / Resources / Limitations), but the sole external reference, `resources/implementation-playbook.md`, is dangling — no `resources/` directory exists in the bundle. Scoring against the actual bundle structure, the broken navigation and duplicated reference line fit anchor 3 (structure present, references problematic) rather than anchor 4's "references mostly clear".	3 / 5
	Total	11 / 20 Passed

Description

61%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.

The description clearly identifies its architectural niche through named patterns, but reads as a capability statement rather than an invocation guide. Its main weaknesses are the missing 'Use when' trigger clause and generic action verbs. Adding explicit trigger phrases would raise both completeness and trigger-term quality.

Suggestions

Append an explicit trigger clause, e.g. "Use when designing or refactoring backend systems, setting architecture standards, or when the user mentions Clean Architecture, Hexagonal Architecture, DDD, or microservices decomposition."

Replace generic verbs ("Master", "build") with concrete actions the skill performs, e.g. "Selects fitting architecture patterns, defines module boundaries and dependency rules, and provides migration steps."

Add natural synonyms users might say ("software architecture", "layered/onion architecture", "domain modeling") to broaden trigger coverage without adding vagueness.

Dimension	Reasoning	Score
Specificity	Names the domain and three concrete patterns ("Clean Architecture, Hexagonal Architecture, and Domain-Driven Design"), but the actions themselves ("Master proven... patterns", "build maintainable, testable, and scalable systems") are generic rather than concrete operations. Anchor 3 fits best: domain plus limited concrete content, not the comprehensive action list of anchor 4.	3 / 5
Completeness	The description clearly answers "what" (master backend architecture patterns) but contains no "Use when..." clause or equivalent explicit trigger guidance; per the judging guidelines, a missing 'Use when' clause caps completeness at 3. Not 2 because the 'what' is explicit and specific rather than vague.	3 / 5
Trigger Term Quality	"Clean Architecture", "Hexagonal Architecture", "Domain-Driven Design", and "backend architecture" are phrases users naturally say when they need this skill, giving good keyword coverage. It falls short of anchor 5 because natural synonyms like "software architecture", "layered/onion architecture", "domain-driven design" shorthand, or "microservices" are missing.	4 / 5
Distinctiveness Conflict Risk	Naming three specific patterns carves a mostly distinct niche ("Clean Architecture, Hexagonal Architecture, and Domain-Driven Design") that is unlikely to trigger the wrong skill. Minor overlap risk remains with closely related skills the body itself lists (event-sourcing, saga-orchestration, workflow automation), keeping it below anchor 5.	4 / 5
	Total	14 / 20 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
Path: skills/antigravity-architecture-patterns/SKILL.md
Commit: 690de8f

Reviewed: 11 minutes 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.