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

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

50%

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

The body provides a thorough, well-structured domain-grouping process with useful templates and fitness-function code, but it is verbose with redundant examples, abstract at the core analysis step, and lacks both a refactoring feedback loop and any file-based progressive disclosure.

Suggestions

Split the monolithic file into one-level-deep references (e.g., FITNESS_FUNCTIONS.md, IMPLEMENTATION_NOTES.md, EXAMPLE_OUTPUTS.md) and keep SKILL.md as a concise overview that links to them.

Add a concrete, executable method for the analysis steps (e.g., how to enumerate components, what to grep/read to derive responsibilities and relationships) instead of abstract directives like "Analyze component responsibilities".

Add an explicit validate→fix→retry feedback loop in Phase 4 (e.g., run tests/build after namespace refactoring, list failure-handling and rollback steps) before marking the refactoring complete.

Dimension	Reasoning	Score
Conciseness	The ~730-line body repeats the same Customer/Ticketing/Reporting examples across Phase 1, Phase 2, Phase 4, and the Output Format sections, and includes generic DDD knowledge Claude already has ("Typical Domains", "Domain Size Guidelines"), so it is mostly useful but could be tightened rather than lean.	2 / 3
Actionability	It offers concrete templates, tables, and executable fitness-function JavaScript, but the core analysis steps are abstract ("Analyze component responsibilities", "Look for business language") with no concrete method for deriving domains from an actual codebase, leaving key execution details missing.	2 / 3
Workflow Clarity	The five-phase sequence is clear with a dedicated validation phase and checklists, but the destructive Phase 4 namespace refactoring only implies "Verify all references updated" without an explicit validate→fix→retry feedback loop, which caps it below 3 for a destructive operation.	2 / 3
Progressive Disclosure	Sections are well-organized, but the skill is a single monolithic ~730-line file with no reference files, and separable material (fitness functions, Node.js/Java implementation notes, example outputs) stays inline rather than being split into one-level-deep references.	2 / 3
	Total	8 / 12 Passed

Description

90%

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 that states a concrete purpose, supplies natural trigger phrases, and proactively distinguishes itself from neighboring skills. Its only weakness is naming a single primary action rather than enumerating multiple concrete capabilities.

Dimension	Reasoning	Score
Specificity	It names the domain and one concrete action ("Groups existing components into logical business domains") plus a purpose ("to plan service-based architecture"), but it does not list multiple specific concrete actions, so it falls short of the level-3 multi-action anchor.	2 / 3
Completeness	It explicitly answers both what (groups components into logical business domains) and when via an explicit "Use when..." clause, satisfying the level-3 anchor rather than the level-2 cap for missing trigger guidance.	3 / 3
Trigger Term Quality	It includes several natural phrasings a user would say ("which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping"), giving good coverage of plausible trigger terms.	3 / 3
Distinctiveness Conflict Risk	It carves a clear niche and explicitly disambiguates from sibling skills with "Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis)", making wrong-skill triggering unlikely.	3 / 3
	Total	11 / 12 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
Commit: 9026164

Reviewed: 4 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.