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).

Quality

65%

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 ./packages/skills-catalog/skills/(architecture)/domain-identification-grouping/SKILL.md

Quality

Content

48%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 thoroughly structured but over-long skill body with clear sequencing and validation, undermined by heavy repetition of the same examples and a monolithic layout that inlines content better placed in reference files. Actionability is mixed: output formats are concrete but the actual domain-identification method is abstract.

Suggestions

Deduplicate the Customer/Ticketing/Reporting domain listings: show them once in the Output Format section and reference it from the phases instead of repeating full enumerations five times.

Move the fitness-function code and full output-format templates into a references/ file (e.g., FITNESS.md, OUTPUT-TEMPLATES.md) and link to them one level deep to shrink SKILL.md to a concise overview.

Add a concrete, executable method or tool step for identifying domains from a real codebase (e.g., a command or script to extract namespaces/dependencies), rather than only abstract analysis instructions.

Dimension	Reasoning	Score
Conciseness	The 700-line body is noticeably verbose: the same Customer/Ticketing/Reporting domain listings are repeated across Phase 1, Phase 2, Domain Map, Output Format, Common Patterns, and Implementation Notes, and it explains concepts (e.g., what a domain is) Claude already knows.	2 / 5
Actionability	Provides concrete output templates and executable fitness-function JavaScript, but the core analysis steps ("Analyze component responsibilities", "Look for business language") are high-level with no concrete method or tooling for actually identifying domains from a codebase.	3 / 5
Workflow Clarity	Clear five-phase sequence with a dedicated validation phase and explicit checklists; falls short of 5 because fix→retry feedback loops are not made explicit (e.g., Phase 4 says "Run tests" but no re-validate loop).	4 / 5
Progressive Disclosure	Well-organized section headers aid navigation, but the skill is a monolithic 700-line file with fitness-function code and full output templates inlined and no references to separate files, where splitting would clearly help.	3 / 5
	Total	12 / 20 Passed

Description

82%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, third-person description that clearly states what the skill does and when to use it, with explicit boundary guidance against overlapping skills. The only weakness is specificity: it names a single main action rather than enumerating several concrete capabilities.

Dimension	Reasoning	Score
Specificity	Names the domain and one concrete action ("Groups existing components into logical business domains to plan service-based architecture"), but does not list several specific actions, matching the anchor for 1-2 concrete actions.	3 / 5
Completeness	Explicitly answers both what (groups components into logical domains for service-based architecture) and when ("Use when asking…"), with concrete trigger phrases.	5 / 5
Trigger Term Quality	Includes several natural phrases users would say ("group these into services", "organize by domain", "component-to-domain mapping", "service extraction from an existing codebase"), though a few synonyms are absent.	4 / 5
Distinctiveness Conflict Risk	Has a clear niche and explicitly disambiguates from sibling skills ("Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis)"), minimizing conflict risk.	5 / 5
	Total	17 / 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
skill_md_line_count	SKILL.md is long (732 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: tech-leads-club/agent-skills
Path: packages/skills-catalog/skills/(architecture)/domain-identification-grouping/SKILL.md
Commit: fe318be

Reviewed: 3 days 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.