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 where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.
SKILL.md
Component Identification and Sizing
This skill identifies architectural components (logical building blocks) in a codebase and calculates size metrics to assess decomposition feasibility and identify oversized components.
How to Use
Quick Start
Request analysis of your codebase:
"Identify and size all components in this codebase"
"Find oversized components that need splitting"
"Create a component inventory for decomposition planning"
"Analyze component size distribution"
Usage Examples
Example 1: Complete Analysis
User: "Identify and size all components in this codebase"
The skill will:
1. Map directory/namespace structures
2. Identify all components (leaf nodes)
3. Calculate size metrics (statements, files, percentages)
4. Generate component inventory table
5. Flag oversized/undersized components
6. Provide recommendations
Example 2: Find Oversized Components
User: "Which components are too large?"
The skill will:
1. Calculate mean and standard deviation
2. Identify components >2 std dev or >10% threshold
3. Analyze functional areas within large components
4. Suggest specific splits with estimated sizes
Example 3: Component Size Analysis
User: "Analyze component sizes and distribution"
The skill will:
1. Calculate all size metrics
2. Generate size distribution summary
3. Identify outliers
4. Provide statistics and recommendations
Step-by-Step Process
Initial Analysis: Start with complete component inventory
Installs
0
Identify Issues: Find components that need attention
Get Recommendations: Request actionable split/consolidation suggestions
Monitor Progress: Track component growth over time
When to Use
Apply this skill when:
Starting a monolithic decomposition effort
Assessing codebase structure and organization
Identifying components that are too large or too small
Creating component inventory for migration planning
Analyzing code distribution across components
Preparing for component-based decomposition patterns
Core Concepts
Component Definition
A component is an architectural building block that:
Has a well-defined role and responsibility
Is identified by a namespace, package structure, or directory path
Contains source code files (classes, functions, modules) grouped together
Performs specific business or infrastructure functionality
Key Rule: Components are identified by leaf nodes in directory/namespace structures. If a namespace is extended (e.g., services/billing extended to services/billing/payment), the parent becomes a subdomain, not a component.
Size Metrics
Statements (not lines of code):
Count executable statements terminated by semicolons or newlines
More accurate than lines of code for size comparison
Accounts for code complexity, not formatting
Component Size Indicators:
Percent of codebase: Component statements / Total statements
File count: Number of source files in component
Standard deviation: Distance from mean component size
Analysis Process
Phase 1: Identify Components
Scan the codebase directory structure:
Map directory/namespace structure
For Node.js: services/, routes/, models/, utils/
For Java: Package structure (e.g., com.company.domain.service)
For Python: Module paths (e.g., app/billing/payment)
Identify leaf nodes
Components are the deepest directories containing source files
Example: services/BillingService/ is a component
Example: services/BillingService/payment/ extends it, making BillingService a subdomain
Create component inventory
List each component with its namespace/path
Note any parent namespaces (subdomains)
Phase 2: Calculate Size Metrics
For each component:
Count statements
Parse source files in component directory
Count executable statements (not comments, blank lines, or declarations alone)
### Recommendations
```markdown
## Recommendations
### High Priority: Split Large Components
**Reporting Component** (33% of codebase):
- **Current**: Single component with 27,765 statements
- **Issue**: Too large, contains multiple functional areas
- **Recommendation**: Split into:
1. Reporting Shared (common utilities)
2. Ticket Reports (ticket-related reports)
3. Expert Reports (expert-related reports)
4. Financial Reports (financial reports)
- **Expected Result**: Each component ~7-9% of codebase
### Medium Priority: Review Small Components
**Login Component** (2% of codebase):
- **Current**: 1,865 statements, 3 files
- **Consideration**: May be too granular if related to broader authentication
- **Recommendation**: Evaluate if should be consolidated with Authentication/User components
### Low Priority: Monitor Well-Sized Components
Most components are appropriately sized. Continue monitoring during decomposition.
Analysis Checklist
Component Identification:
Mapped all directory/namespace structures
Identified leaf nodes (components) vs parent nodes (subdomains)
Created complete component inventory
Documented namespace/path for each component
Size Calculation:
Counted statements (not lines) for each component
Counted source files (excluding tests/configs)
Calculated percentage of total codebase
Calculated mean and standard deviation
Size Assessment:
Identified oversized components (>threshold or >2 std dev)
Identified undersized components (<1% or <1 std dev)
Flagged components for splitting or consolidation
Documented size distribution
Recommendations:
Suggested splits for oversized components
Suggested consolidations for undersized components
