/component-common-domain-detection
Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before
$ npx -y skills add tech-leads-club/agent-skills --skill component-common-domain-detection --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/component-common-domain-detection
Context preview
The summary Claude sees to decide when to auto-load this skill.
Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before
SKILL.md
component-common-domain-detection.SKILL.mdname: component-common-domain-detection
description: Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
Common Domain Component Detection
This skill identifies common domain functionality that is duplicated across multiple components and suggests consolidation opportunities to reduce duplication and improve maintainability.
How to Use
Quick Start
Request analysis of your codebase:
- **"Find common domain functionality across components"**
- **"Identify duplicate domain logic that should be consolidated"**
- **"Detect shared classes used across multiple components"**
- **"Analyze consolidation opportunities for common components"**
Usage Examples
**Example 1: Find Common Functionality**
User: "Find common domain functionality across components"
The skill will:
1. Scan component namespaces for common patterns
2. Detect shared classes used across components
3. Identify duplicate domain logic
4. Analyze coupling impact of consolidation
5. Suggest consolidation opportunities
**Example 2: Detect Duplicate Notification Logic**
User: "Are there multiple notification components that should be consolidated?"
The skill will:
1. Find all components with notification-related names
2. Analyze their functionality and dependencies
3. Calculate coupling impact if consolidated
4. Recommend consolidation approach
**Example 3: Analyze Shared Classes**
User: "Find classes that are shared across multiple components"
The skill will:
1. Identify classes imported/used by multiple components
2. Classify as domain vs infrastructure functionality
3. Suggest consolidation or shared library approach
4. Assess impact on coupling
Step-by-Step Process
1. **Scan Components**: Identify components with common namespace patterns 2. **Detect Shared Code**: Find classes/files used across components 3. **Analyze Functionality**: Determine if functionality is truly common 4. **Assess Coupling**: Calculate coupling impact before consolidation 5. **Recommend Actions**: Suggest consolidation or shared library approach
When to Use
Apply this skill when:
- After identifying and sizing components (Pattern 1)
- Before flattening components (Pattern 3)
- When planning to reduce code duplication
- Analyzing shared domain logic across the codebase
- Preparing for component consolidation
- Identifying candidates for shared services or libraries
Core Concepts
Domain vs Infrastructure Functionality
**Domain Functionality** (candidates for consolidation):
- Business processing logic (notification, validation, auditing, formatting)
- Common to **some** processes, not all
- Examples: Customer notification, ticket auditing, data validation
**Infrastructure Functionality** (usually not consolidated here):
- Operational concerns (logging, metrics, security)
- Common to **all** processes
- Examples: Logging, authentication, database connections
Common Domain Patterns
Common domain functionality often appears as:
1. **Namespace Patterns**: Components ending in same leaf node
- `*.notification`, `*.audit`, `*.validation`, `*.formatting`
- Example: `TicketNotification`, `BillingNotification`, `SurveyNotification`
2. **Shared Classes**: Same class used across multiple components
- Example: `SMTPConnection` used by 5 different components
- Example: `AuditLogger` used by multiple domain components
3. **Similar Functionality**: Different components doing similar things
- Example: Multiple components sending emails with slight variations
- Example: Multiple components writing audit logs
Consolidation Approaches
**Shared Service**:
- Common functionality becomes a separate service
- Other components call this service
- Good for: Frequently changing logic, complex operations
**Shared Library**:
- Common code packaged as library (JAR, DLL, npm package)
- Components import and use the library
- Good for: Stable functionality, simple utilities
**Component Consolidation**:
- Merge multiple components into one
- Good for: Highly related functionality, low coupling impact
Analysis Process
Phase 1: Identify Common Namespace Patterns
Scan component namespaces for common leaf node names:
1. **Extract leaf nodes** from all component namespaces
- Example: `services/billing/notification` → `notification`
- Example: `services/ticket/notification` → `notification`
2. **Group by common leaf nodes**
- Find components with same leaf node name
- Example: All components ending in `.notification`
3. **Filter out infrastructure patterns**
- Exclude: `.util`, `.helper`, `.common` (usually infrastructure)
- Focus on: `.notification`, `.audit`, `.validation`, `.formatting`
**Example Output**:
## Common Namespace Patterns Found
**Notification Components**:
- services/customer/notification
- services/ticket/notification
- services/survey/notification
**Audit Components**:
- services/billing/audit
- services/ticket/audit
- services/survey/audit
Phase 2: Detect Shared Classes
Find classes/files used across multiple components:
1. **Scan imports/dependencies** in each component
- Track which classes are imported from where
- Note classes used by multiple components
2. **Identify shared classes**
- Classes imported by 2+ components
- Exclude infrastructure classes (Logger, Config, etc.)
3. **Classify as domain vs infrastructure**
- Domain: Business logic classes (SMTPConnection, AuditLogger)
- Infrastructure: Technical utilities (Logger, DatabaseConnection)
**Example Output**:
## Shared Classes Found
**Domain Classes**:
- `SMTP
Read more
name: component-common-domain-detection description: Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).
Common Domain Component Detection
This skill identifies common domain functionality that is duplicated across multiple components and suggests consolidation opportunities to reduce duplication and improve maintainability.
How to Use
Quick Start
Request analysis of your codebase:
- **"Find common domain functionality across components"**
- **"Identify duplicate domain logic that should be consolidated"**
- **"Detect shared classes used across multiple components"**
- **"Analyze consolidation opportunities for common components"**
Usage Examples
**Example 1: Find Common Functionality**
User: "Find common domain functionality across components" The skill will: 1. Scan component namespaces for common patterns 2. Detect shared classes used across components 3. Identify duplicate domain logic 4. Analyze coupling impact of consolidation 5. Suggest consolidation opportunities
**Example 2: Detect Duplicate Notification Logic**
User: "Are there multiple notification components that should be consolidated?" The skill will: 1. Find all components with notification-related names 2. Analyze their functionality and dependencies 3. Calculate coupling impact if consolidated 4. Recommend consolidation approach
**Example 3: Analyze Shared Classes**
User: "Find classes that are shared across multiple components" The skill will: 1. Identify classes imported/used by multiple components 2. Classify as domain vs infrastructure functionality 3. Suggest consolidation or shared library approach 4. Assess impact on coupling
Step-by-Step Process
1. **Scan Components**: Identify components with common namespace patterns 2. **Detect Shared Code**: Find classes/files used across components 3. **Analyze Functionality**: Determine if functionality is truly common 4. **Assess Coupling**: Calculate coupling impact before consolidation 5. **Recommend Actions**: Suggest consolidation or shared library approach
When to Use
Apply this skill when:
- After identifying and sizing components (Pattern 1)
- Before flattening components (Pattern 3)
- When planning to reduce code duplication
- Analyzing shared domain logic across the codebase
- Preparing for component consolidation
- Identifying candidates for shared services or libraries
Core Concepts
Domain vs Infrastructure Functionality
**Domain Functionality** (candidates for consolidation):
- Business processing logic (notification, validation, auditing, formatting)
- Common to **some** processes, not all
- Examples: Customer notification, ticket auditing, data validation
**Infrastructure Functionality** (usually not consolidated here):
- Operational concerns (logging, metrics, security)
- Common to **all** processes
- Examples: Logging, authentication, database connections
Common Domain Patterns
Common domain functionality often appears as:
1. **Namespace Patterns**: Components ending in same leaf node
- `*.notification`, `*.audit`, `*.validation`, `*.formatting`
- Example: `TicketNotification`, `BillingNotification`, `SurveyNotification`
2. **Shared Classes**: Same class used across multiple components
- Example: `SMTPConnection` used by 5 different components
- Example: `AuditLogger` used by multiple domain components
3. **Similar Functionality**: Different components doing similar things
- Example: Multiple components sending emails with slight variations
- Example: Multiple components writing audit logs
Consolidation Approaches
**Shared Service**:
- Common functionality becomes a separate service
- Other components call this service
- Good for: Frequently changing logic, complex operations
**Shared Library**:
- Common code packaged as library (JAR, DLL, npm package)
- Components import and use the library
- Good for: Stable functionality, simple utilities
**Component Consolidation**:
- Merge multiple components into one
- Good for: Highly related functionality, low coupling impact
Analysis Process
Phase 1: Identify Common Namespace Patterns
Scan component namespaces for common leaf node names:
1. **Extract leaf nodes** from all component namespaces
- Example: `services/billing/notification` → `notification`
- Example: `services/ticket/notification` → `notification`
2. **Group by common leaf nodes**
- Find components with same leaf node name
- Example: All components ending in `.notification`
3. **Filter out infrastructure patterns**
- Exclude: `.util`, `.helper`, `.common` (usually infrastructure)
- Focus on: `.notification`, `.audit`, `.validation`, `.formatting`
**Example Output**:
## Common Namespace Patterns Found **Notification Components**: - services/customer/notification - services/ticket/notification - services/survey/notification **Audit Components**: - services/billing/audit - services/ticket/audit - services/survey/audit
Phase 2: Detect Shared Classes
Find classes/files used across multiple components:
1. **Scan imports/dependencies** in each component
- Track which classes are imported from where
- Note classes used by multiple components
2. **Identify shared classes**
- Classes imported by 2+ components
- Exclude infrastructure classes (Logger, Config, etc.)
3. **Classify as domain vs infrastructure**
- Domain: Business logic classes (SMTPConnection, AuditLogger)
- Infrastructure: Technical utilities (Logger, DatabaseConnection)
**Example Output**:
## Shared Classes Found **Domain Classes**: - `SMTP
The secure, validated skill registry for professional AI coding agents. Extend Antigravity, Claude Code, Cursor, Copilot and more with absolute confidence.
Repo: tech-leads-club/agent-skills
Other skills on tech-leads-club-agent-skills.
- /component-flattening-analysis
Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or
Open skill - /component-identification-sizing
Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning
Open skill - /coupling-analysis
Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I
Open skill - /decomposition-planning-roadmap
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices
Open skill - /domain-analysis
Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing
Open skill - /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
Open skill

