Identifies architectural components in codebases and calculates size metrics for decomposition planning. Use when analyzing codebase structure, planning monolithic decomposition, identifying oversized components, calculating component statistics, or when the user asks about component analysis, codebase sizing, or architectural decomposition.
A skill for identifying architectural components in codebases and calculating size metrics to support decomposition planning and migration efforts.
This skill analyzes codebases to:
This skill is applied when you:
This skill works with any codebase in any language:
services/, routes/, models/ directoriescom.company.domain.service)app/billing/payment)Uses statements (not lines of code) for accurate size comparison:
Provides concrete, actionable analysis:
The primary skill file containing:
Fast reference for common scenarios:
Complete documentation including:
User: "Identify and size all components in this codebase"
The skill will:
1. Map directory/namespace structures
2. Identify leaf nodes (components)
3. Count statements and files per component
4. Calculate percentages and statistics
5. Generate component inventory table
6. Flag oversized/undersized components
Output:
## Component Inventory
| Component Name | Namespace | Statements | Files | Percent | Status |
| ------------------- | ---------------------------- | ---------- | ----- | ------- | ------------ |
| BillingService | services/BillingService | 4,312 | 23 | 5% | ✅ OK |
| ReportingService | services/ReportingService | 27,765 | 162 | 33% | ⚠️ Too Large |
| NotificationService | services/NotificationService | 1,433 | 7 | 2% | ✅ OK |
## Recommendations
- ReportingService (33%) should be split into smaller components
User: "Find components that are too large and need splitting"
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
5. Estimate resulting component sizes
Output:
## Oversized Components
**ReportingService** (33% - 27,765 statements)
- Exceeds 10% threshold
- Contains multiple functional areas:
- Ticket Reports (8,000 statements)
- Expert Reports (9,000 statements)
- Financial Reports (10,000 statements)
- Shared utilities (765 statements)
**Recommendation**: Split into:
1. ReportingShared (shared utilities)
2. TicketReportsService
3. ExpertReportsService
4. FinancialReportsService
User: "Analyze component sizes and distribution"
The skill will:
1. Calculate all size metrics
2. Generate size distribution
3. Identify outliers
4. Provide summary statistics
5. Create recommendations
Output:
## Size Analysis Summary
**Total Components**: 18
**Total Statements**: 82,931
**Mean Component Size**: 4,607 statements
**Standard Deviation**: 5,234 statements
**Distribution**:
- Oversized (>2 std dev): 1 component
- Well-sized (within 1-2 std dev): 15 components
- Undersized (<1 std dev): 2 components
A component is an architectural building block that:
Key Rule: Components are leaf nodes only. If a namespace is extended (e.g., services/billing → services/billing/payment), the parent becomes a subdomain, not a component.
| Metric | Description | Purpose |
| -------------- | ---------------------------------------------------------- | ---------------------------------------------- |
| Statements | Count executable statements (terminated by ; or newline) | Accurate size measure, accounts for complexity |
| Files | Count source files in component | Complexity indicator |
| Percent | (component_statements / total_statements) * 100 | Relative size in codebase |
| Std Dev | Standard deviation from mean component size | Outlier detection |
Thresholds vary by application size:
| App Size | Oversized Threshold | Notes | | ------------------------- | ------------------- | -------------------------------------------- | | Small (<10 components) | >30% of codebase | Fewer components, higher variance acceptable | | Medium (10-20 components) | >15% of codebase | Balanced threshold | | Large (>20 components) | >10% of codebase | More components, lower variance expected |
Standard Deviation Rule: Components >2 standard deviations from mean are considered oversized.
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"
Start with a complete component inventory:
User: "Identify all components and calculate their sizes"
This will:
Find components that need attention:
User: "Which components are too large and need splitting?"
This will:
Request actionable recommendations:
User: "What should I do about oversized components?"
This will:
Track changes over time:
User: "Has component X grown too large since last analysis?"
This will:
If you have specific size requirements:
User: "Identify components larger than 15% of the codebase"
For framework-specific analysis:
User: "Analyze components in the services/ directory"
Analyze specific domains:
User: "Size all components in the billing domain"
The skill generates structured output:
## Component Inventory
| Component Name | Namespace/Path | Statements | Files | Percent | Status |
| ---------------- | ------------------------- | ---------- | ----- | ------- | ------------ |
| BillingService | services/BillingService | 4,312 | 23 | 5% | ✅ OK |
| ReportingService | services/ReportingService | 27,765 | 162 | 33% | ⚠️ Too Large |
## Size Analysis Summary
**Total Components**: 18
**Total Statements**: 82,931
**Mean Component Size**: 4,607 statements
**Standard Deviation**: 5,234 statements
**Oversized Components** (>2 std dev or >10%):
- ReportingService (33% - 27,765 statements)
## Recommendations
### High Priority: Split Large Components
**ReportingService** (33% of codebase):
- **Current**: Single component with 27,765 statements
- **Issue**: Too large, contains multiple functional areas
- **Recommendation**: Split into:
1. ReportingShared (common utilities)
2. TicketReportsService
3. ExpertReportsService
4. FinancialReportsService
- **Expected Result**: Each component ~7-9% of codebase
This skill is part of a decomposition pattern sequence:
Use this skill first to establish a baseline before applying other decomposition patterns.
This skill is installed at the project level:
skills/component-identification-sizing/
This means it's:
The skill will be automatically discovered and used when appropriate based on the description in the frontmatter.
If your project has specific component patterns, document them:
skills/component-identification-sizing/
└── project-patterns.md # Document project-specific component patterns
Add framework-specific detection patterns:
## Framework: NestJS
**Component Pattern**: `@Injectable()` classes in `services/` directory
**Module Pattern**: `@Module()` decorator groups components
**Controller Pattern**: `@Controller()` in `controllers/` directory
Modify thresholds in SKILL.md for your project:
## Custom Thresholds
For this project:
- Oversized: >12% of codebase (instead of default 10%)
- Undersized: <0.5% of codebase (instead of default 1%)
After identifying components, create automated checks:
// Alert if component exceeds threshold
function checkComponentSize(component, totalStatements, threshold = 0.1) {
const percent = component.statements / totalStatements
if (percent > threshold) {
return {
component: component.name,
percent: (percent * 100).toFixed(1),
issue: 'Exceeds size threshold',
}
}
}
// Alert if component is >2 std dev from mean
function checkStandardDeviation(component, mean, stdDev) {
const deviation = Math.abs(component.statements - mean) / stdDev
if (deviation > 2) {
return {
component: component.name,
deviation: deviation.toFixed(2),
issue: 'More than 2 standard deviations from mean',
}
}
}
To verify the skill works correctly, try:
User: "Identify and size all components in this codebase"
The skill should:
Issue: Components are not found in your structure
Solution:
Issue: Size metrics seem wrong
Solution:
Issue: Too many/few components flagged
Solution:
This skill is based on:
To improve this skill:
Version: 1.0.0
Created: 2026-02-05
Based on: Component-Based Decomposition Patterns from "Software Architecture: The Hard Parts"
To use this skill immediately:
User: "Identify and size all components in my codebase"
User: "Find oversized components that need splitting"
User: "Create a component inventory for decomposition planning"
User: "Analyze component size distribution"
This skill will automatically be applied to provide comprehensive analysis with actionable recommendations.
npx skills add tech-leads-club/component-identification-sizing下载完整 Skill 目录，包含 SKILL.md 及所有相关文件
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer