CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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.

55

Quality

69%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/architecture-patterns/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A lean, well-sectioned overview whose substance is entirely missing: it defers all concrete material to a playbook file that is not in the bundle, leaving only abstract instruction steps. The result is a skill that reads well but executes poorly — no decision criteria, examples, or validation checkpoints, and a broken reference stated twice.

Suggestions

Fix the broken reference: `resources/implementation-playbook.md` does not exist in the bundle — either create the playbook containing the promised patterns, checklists, and templates, or inline the essential guidance (pattern-selection criteria, example module boundaries and dependency rules) into SKILL.md.

Make the instruction steps actionable: replace 'Select an architecture pattern that fits the domain complexity' with concrete decision criteria (e.g., a mapping of domain complexity / team size / coupling pain points to Clean vs. Hexagonal vs. DDD), and add an example dependency-rule or module-boundary snippet plus a worked migration checklist with validation steps.

Remove duplication: the reference is stated twice (end of Instructions and in Resources) and the intro paragraph repeats the frontmatter description verbatim — keep one pointer to the playbook and drop the echoed description.

DimensionReasoningScore

Conciseness

The body is short with no over-explanation of concepts Claude already knows, but it is not tight: the intro sentence echoes the frontmatter description nearly verbatim, the 'Use/Do not use' lists duplicate the description's triggers, and the reference to `resources/implementation-playbook.md` is stated twice (in Instructions and again in Resources). This matches 'mostly efficient but could be tightened' rather than a 4, where only minor trimming would be needed — three separate redundancies are present.

3 / 5

Actionability

The four steps are high-level hints — 'Clarify domain boundaries, constraints, and scalability targets', 'Select an architecture pattern that fits the domain complexity', 'Define module boundaries, interfaces, and dependency rules' — with no decision criteria for choosing among Clean/Hexagonal/DDD, no example boundary or dependency-rule structures, and no concrete migration steps. This matches the 'minimal concrete guidance; high-level hints but missing the specific steps to execute' anchor; it is not a 3 because even the details it promises ('detailed patterns, checklists, and templates') live in a referenced file that does not exist in the bundle, leaving no concrete material at all.

2 / 5

Workflow Clarity

The four numbered steps form a coherent sequence (clarify → select → define → provide migration/validation), matching 'steps listed but validation gaps; checkpoints missing or implicit'. Validation appears only as a deliverable to 'provide', never as an actual checkpoint in the workflow. Not a 2 because, unlike the 2-anchor, the sequence is present and each step maps to a distinct, sensibly ordered phase; not a 4 because the steps themselves are vaguely defined and no verification checkpoint is explicit.

3 / 5

Progressive Disclosure

Scored against the actual bundle structure as the guidelines direct: there are no `references/`, `scripts/`, `assets/`, or `resources/` files, so `resources/implementation-playbook.md` — to which the skill defers all detailed patterns, checklists, and templates — does not exist. The on-paper structure (clear sections, one clearly signaled one-level reference) would suggest a 4, but the bundle delivers nothing beyond the overview, so the skill is neither self-contained nor appropriately split; this lands noticeably below the midpoint. Not a 1 because the body itself is navigable with clear headers and the reference is signaled, not buried.

2 / 5

Total

10

/

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 following best-practice form: concrete 'what' with named patterns and an explicit 'Use when' trigger clause in appropriate third-person voice. Gaps are limited — a few natural synonym triggers (onion, ports-and-adapters, DDD) and a minor overlap risk on the broad 'refactoring' trigger.

DimensionReasoningScore

Specificity

The description names the domain and three concrete patterns ('Clean Architecture, Hexagonal Architecture, and Domain-Driven Design') plus actions ('Implement', 'architecting', 'refactoring'), matching the 'several specific actions with minor gaps' anchor. It falls short of a 5 because 'Implement' is the only capability verb — it does not state what it does with those patterns (e.g., define module boundaries, produce migration plans), leaving minor coverage gaps.

4 / 5

Completeness

Both parts are explicit: the 'what' is 'Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design' and the 'when' is 'Use when architecting complex backend systems or refactoring existing applications for better maintainability' — a concrete trigger clause that mirrors the 5-anchor example's structure. It is not a 4 because the 'when' clause is already explicit and specific rather than merely present.

5 / 5

Trigger Term Quality

Good natural-keyword coverage: 'backend architecture', 'Clean Architecture', 'Hexagonal Architecture', 'Domain-Driven Design', 'architecting complex backend systems', 'refactoring', 'maintainability' — phrases users would actually say. Not a 5 because common synonyms and variations are missing ('onion architecture', 'ports and adapters', 'DDD', 'domain modeling').

4 / 5

Distinctiveness Conflict Risk

The Clean/Hexagonal/DDD niche is clear and mostly distinct from generic coding skills, matching the 'mostly distinct; minor overlap risk' anchor. Not a 5 because 'refactoring existing applications for better maintainability' could overlap with a general refactoring or code-quality skill's triggers.

4 / 5

Total

17

/

20

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

Validation for skill structure

No warnings or errors.

Repository

rmyndharis/antigravity-skills

Path

skills/architecture-patterns/SKILL.md

Reviewed

Table of Contents

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.