CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

design-patterns

Select and apply structural design patterns (Strategy, Factory, Adapter, Observer, etc.) to reduce complexity in class design. Use when evaluating whether a pattern solves a concrete problem, refactoring conditional logic, dealing with too many if/else statements or code smells, resolving inheritance problems, or deciding how to structure classes.

Quality

80%

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/software-engineering/design-principles/design-patterns/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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 well-structured, actionable skill body with a clear selection workflow, strong anti-pattern guidance, and a verified one-level-deep reference bundle. The main weakness is token efficiency: roughly half the body catalogs standard GoF patterns with code Claude already knows, which could be trimmed or moved to a reference file.

Suggestions

Trim the Common Patterns catalog: keep one compact before/after example per pattern and move full implementations (Observer, Adapter, Humble Object boilerplate) to references/detailed-examples.md, which already exists for this purpose.

Make code examples fully executable by replacing "/* ... */" placeholder bodies and undefined types (Email, Receipt, Event) with minimal complete definitions, and keep the rg quick commands as the primary executable entry point.

Add a final validation step to the workflow (e.g., "confirm the win condition is met after refactoring; if not, revert or reconsider the pattern") and one line of 'read when' guidance per reference file in the References section.

DimensionReasoningScore

Conciseness

The body is mostly efficient (tight anti-pattern entries with WHY rationale, compact quick commands), but the "Common Patterns" section re-explains textbook GoF patterns (Observer boilerplate, Adapter, Humble Object) Claude already knows. Not a 2 because prose is sparse and the examples are compact rather than padded.

3 / 5

Actionability

Runnable rg commands, before/after TypeScript examples, and per-step output templates give mostly executable guidance. Minor gaps keep it below 5: several examples use "/* ... */" placeholder bodies and undefined types (Email, Receipt, Event) rather than fully copy-paste-ready code.

4 / 5

Workflow Clarity

The three-step selection workflow has explicit per-step outputs, a "measurable, not aspirational" win-condition checkpoint, and a Validation line in the documentation template. It lacks an explicit post-application feedback loop (verify the win condition was actually met), so it does not reach the 5 anchor; not a destructive or batch skill, so no cap applies.

4 / 5

Progressive Disclosure

Well-sectioned overview with 11 labeled references that all exist and are one level deep (no nested references, verified), matching the good-structure anchor. Minor gaps: the reference list gives no "read this when" guidance, and inline pattern examples partially duplicate references/detailed-examples.md.

4 / 5

Total

15

/

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: it states concrete capabilities with named patterns and an explicit, multi-trigger "Use when" clause covering natural user phrasing. Distinctiveness is good, with only minor overlap risk against adjacent refactoring/architecture skills.

DimensionReasoningScore

Specificity

"Select and apply structural design patterns (Strategy, Factory, Adapter, Observer, etc.) to reduce complexity in class design" names the domain, two concrete actions, and specific patterns. It falls just short of the 5 anchor's comprehensive multi-action coverage (no mention of evaluating or documenting outcomes, which the body actually covers).

4 / 5

Completeness

It explicitly answers both what ("Select and apply structural design patterns ... to reduce complexity in class design") and when, with an explicit "Use when" clause containing five concrete trigger phrases. This matches the 5 anchor directly rather than the 4 anchor, whose 'when' is less specific.

5 / 5

Trigger Term Quality

"Refactoring conditional logic", "too many if/else statements or code smells", "resolving inheritance problems", and "deciding how to structure classes" are natural phrases users would say. A few common variants (e.g., "switch statements", "polymorphism") are missing, keeping it below the 5 anchor.

4 / 5

Distinctiveness Conflict Risk

The class-design scope and triggers like "if/else statements" and "inheritance problems" carve a clear niche distinct from sibling skills (solid-principles, clean-architecture). Minor overlap risk remains with general refactoring skills, so it does not reach the 5 anchor's minimal-conflict bar.

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

pantheon-org/tekhne

Path

skills/software-engineering/design-principles/design-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.