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).
70
63%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./packages/skills-catalog/skills/(architecture)/domain-identification-grouping/SKILL.mdQuality
Discovery
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 a specific action, includes natural trigger terms users would say, explicitly addresses both what and when, and proactively distinguishes itself from related skills with 'Do NOT use' guidance. The negative boundary clauses referencing specific alternative skills are a particularly strong feature for disambiguation in a multi-skill environment.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description lists a concrete action ('Groups existing components into logical business domains to plan service-based architecture') and further specifies the scope by clarifying what it does NOT do (identifying new domains, analyzing coupling), which adds precision. | 3 / 3 |
Completeness | Clearly answers both 'what' (groups existing components into logical business domains for service-based architecture planning) and 'when' (explicit 'Use when' clause with multiple trigger phrases). Additionally includes 'Do NOT use' guidance to prevent misuse, which goes beyond the minimum requirement. | 3 / 3 |
Trigger Term Quality | Includes highly natural trigger phrases users would say: 'which components belong together?', 'group these into services', 'organize by domain', 'component-to-domain mapping', 'service extraction'. These cover multiple natural variations of how a user might phrase the request. | 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 clearly carves out a niche and minimizes overlap with related skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
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 and highly repetitive, with the same domain examples and concepts restated across multiple sections. While it provides a structured multi-phase process and some useful artifacts (namespace refactoring tables, fitness functions, directory structures), the sheer volume of content (~400+ lines) undermines its utility as a skill file. The content would be significantly improved by aggressive deduplication, splitting detailed templates into separate files, and focusing the main skill on the core decision-making process.
Suggestions
Reduce content by at least 50% by eliminating repeated examples (the Customer/Ticketing/Reporting domain example appears 4+ times) and consolidating redundant sections (Notes, Best Practices, and Core Concepts all say 'domains = business capabilities, not technical layers').
Extract output format templates, fitness function code, and implementation notes into separate referenced files (e.g., OUTPUT_TEMPLATES.md, FITNESS_FUNCTIONS.md) to improve progressive disclosure.
Make the analysis process more actionable by specifying concrete steps Claude can execute: e.g., 'grep for import statements to map dependencies', 'count shared data models between components', rather than abstract guidance like 'analyze component relationships'.
Remove explanations of basic concepts Claude already knows (what a domain is, what namespaces are, what cohesion means) and focus on the specific heuristics and decision criteria unique to this skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose and repetitive. The same examples (Customer/Ticketing/Reporting domains, namespace refactoring tables) are repeated 3-4 times across different sections. Concepts like 'what a domain is' and 'group by business capability' are over-explained. The content could be reduced by 60-70% without losing information. Many sections (Best Practices, Notes, Common Domain Patterns) repeat the same advice. | 1 / 3 |
Actionability | Provides some concrete examples like namespace refactoring tables and directory structures, plus fitness function code snippets. However, much of the guidance is procedural description ('analyze component responsibilities', 'collaborate with stakeholders') rather than executable steps Claude can directly perform. The fitness function code is useful but the core analysis process lacks concrete tooling or commands. | 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 mostly subjective ('check cohesion', 'verify boundaries', 'get stakeholder validation') rather than concrete automated checks. The namespace refactoring phase mentions 'run tests to verify changes' but lacks specific validation commands or error recovery steps. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. Everything is inline, including detailed output format examples, implementation notes for multiple languages, fitness functions, best practices, common patterns, and domain size guidelines. This content would benefit enormously from splitting into separate reference files (e.g., OUTPUT_TEMPLATES.md, FITNESS_FUNCTIONS.md, EXAMPLES.md). | 1 / 3 |
Total | 6 / 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.
Validation — 10 / 11 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 | 10 / 11 Passed | |
- Repository
- tech-leads-club/agent-skills
- Commit
81e7e0d
- 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.