CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

domain-driven-design

Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns.

Quality

75%

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 ./plugins/AI-Agents-Safe-Coding-Skills/skills/domain-driven-design/SKILL.md

The canonical home for this skill is domain-driven-design in administrakt0r/AI-Agents-Safe-Coding-Skills

SKILL.md
Quality
Evals
Security

Quality

Content

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

This is a strong router-style skill body: lean, well-sectioned, and actionable, with an explicit viability gate, a concrete routing map, and a genuine one-level-deep reference file that matches its citation. The only meaningful gap is the absence of a concrete example of the required output or an artifact, which keeps actionability and workflow clarity at 4.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence: terse bullet sections with no explanation of what DDD is or how the patterns work, and every section (use/do-not-use, viability check, routing map, output requirements, limitations) earns its place.

5 / 5

Actionability

Guidance is concrete throughout — the two-of-four viability criteria, exact routing targets like `@ddd-strategic-design` and `@cqrs-implementation`, and named artifacts (subdomains, bounded contexts, language glossary). It falls short of a 5 only because there is no worked example of what the required output or an artifact actually looks like.

4 / 5

Workflow Clarity

A clear numbered sequence exists with an explicit decision gate (the viability check) before committing and strategic-first ordering, but step 4's 'success criteria and evidence' are named without any checkpoint for how to verify them, matching anchor 4 rather than 5.

4 / 5

Progressive Disclosure

SKILL.md is a well-organized overview with one clearly signaled, one-level-deep reference ('If templates are needed, open references/ddd-deliverables.md'), and that file exists and delivers exactly the promised deliverable templates — clear navigation with no buried or nested references.

5 / 5

Total

18

/

20

Passed

Description

53%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 communicates a clear, staged what for the DDD niche, but it has no 'Use when' trigger clause, omits high-traffic synonyms like 'DDD', 'bounded contexts', 'CQRS', and 'event sourcing', and stops at two generic verbs ('plan', 'route'). These gaps leave it squarely at the midpoint of the rubric despite the body being strong.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when modeling a complex business domain, defining bounded contexts, or deciding whether to adopt full DDD, CQRS, or event sourcing.'

Include the natural trigger terms users actually say — the 'DDD' abbreviation, 'bounded contexts', 'ubiquitous language', 'CQRS', 'event sourcing', and 'domain modeling' — to raise trigger term coverage.

Sharpen the action verbs beyond 'plan and route' by naming what the skill produces, e.g. 'assess DDD viability, map subdomains and bounded contexts, and route to the right tactical or evented pattern.'

DimensionReasoningScore

Specificity

The description names the domain ('Domain-Driven Design') and two concrete actions ('Plan and route') plus three stage scopes ('strategic modeling', 'tactical implementation', 'evented architecture patterns'), matching anchor 3 — clear but not comprehensive. It is not a 4 because only two verbs are given and no artifact-level or deliverable-level actions are named.

3 / 5

Completeness

It has a clear 'what' ('Plan and route Domain-Driven Design work...') but no 'Use when...' clause or equivalent explicit trigger guidance anywhere in the description, which per the judging guidelines caps completeness at 3. It is not a 2 because the 'what' is specific and staged rather than vague.

3 / 5

Trigger Term Quality

'Domain-Driven Design' is the natural phrase a user would say, but common variations and synonyms are missing: the 'DDD' abbreviation, 'bounded contexts', 'CQRS', 'event sourcing', and 'domain modeling' — matching anchor 3 ('some relevant keywords but missing common variations or synonyms'). It is not a 4 because several of the most likely user trigger terms are absent.

3 / 5

Distinctiveness Conflict Risk

'Domain-Driven Design' is a clear niche with mostly distinct triggers, so it is well above anchor 3. It is not a 5 because without any when-boundaries in the description, it could plausibly fire for general software-architecture or microservices-design requests — minor overlap risk with closely related skills.

4 / 5

Total

13

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

administrakt0r/AI-Agents-Safe-Coding-Skills

Path

plugins/AI-Agents-Safe-Coding-Skills/skills/domain-driven-design/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.