CtrlK
BlogDocsLog inGet started
Tessl Logo

domain-identification-grouping

Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).

56

Quality

63%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./packages/skills-catalog/skills/(architecture)/domain-identification-grouping/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

27%

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

This skill is excessively verbose, repeating the same domain examples (Customer, Ticketing, Reporting) at least 5 times across different sections. The content explains concepts Claude already understands (what a business domain is, how to group related things) and could be reduced by 70%+ without losing actionable information. The fitness function code and namespace refactoring tables are the strongest elements, but they're buried in repetitive content.

Suggestions

Reduce content to ~100 lines by eliminating repeated examples - show the Customer/Ticketing domain mapping once, not in every section

Remove explanations of basic concepts Claude already knows (what a domain is, why grouping matters) and focus on the specific heuristics and decision criteria that are unique to this skill

Split output format templates, fitness functions, and implementation notes (Node.js/Java) into separate reference files to improve progressive disclosure

Add concrete validation criteria instead of subjective checks - e.g., 'if >50% of a component's dependencies are outside its domain, it may be misassigned' rather than 'check cohesion'

DimensionReasoningScore

Conciseness

Extremely verbose and repetitive. The same examples (Customer Domain, Ticketing Domain, etc.) are repeated 5+ times across different sections. Concepts like 'what a domain is' and 'business capability grouping' are over-explained. The skill is ~400 lines when it could be ~100. Much content restates what Claude already knows about organizing code by business domain.

1 / 3

Actionability

Provides some concrete examples of namespace mappings and directory structures, plus fitness function code snippets. However, the core guidance is largely descriptive ('analyze component responsibilities', 'identify business capabilities') rather than providing executable commands or tools. The fitness function code is useful but not tied to any specific tooling or execution context.

2 / 3

Workflow Clarity

The 5-phase process is clearly sequenced and includes a validation phase (Phase 3) with a checklist. However, the validation is subjective ('check cohesion', 'verify boundaries') rather than providing concrete automated validation steps. The 'Get Stakeholder Validation' step is repeated in multiple phases without adding clarity. Missing concrete feedback loops for error recovery.

2 / 3

Progressive Disclosure

Monolithic wall of text with no references to external files. All content is inline including detailed output format examples, implementation notes for multiple languages, fitness functions, best practices, common patterns, and domain size guidelines. Much of this could be split into separate reference files. No bundle files exist to support progressive disclosure.

1 / 3

Total

6

/

12

Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is an excellent skill description that hits all the marks. It provides specific actions, comprehensive trigger terms users would naturally use, explicit 'Use when' and 'Do NOT use' clauses, and clear boundaries distinguishing it from related skills like domain-analysis and coupling-analysis.

DimensionReasoningScore

Specificity

The description lists concrete actions: 'Groups existing components into logical business domains' and 'plan service-based architecture'. It also specifies what it does NOT do, adding further clarity.

3 / 3

Completeness

Clearly answers both 'what' (groups components into logical business domains for service-based architecture) and 'when' (explicit 'Use when' clause with multiple trigger phrases). Also includes 'Do NOT use' guidance for disambiguation.

3 / 3

Trigger Term Quality

Excellent coverage of natural trigger terms: 'which components belong together?', 'group these into services', 'organize by domain', 'component-to-domain mapping', 'service extraction'. These are phrases users would naturally say.

3 / 3

Distinctiveness Conflict Risk

Highly distinctive with explicit boundary-setting via 'Do NOT use for' clauses that reference specific alternative skills (domain-analysis, coupling-analysis). This makes it very unlikely to conflict with related skills.

3 / 3

Total

12

/

12

Passed

Validation

90%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (732 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Repository
tech-leads-club/agent-skills
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.