重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
component-identification-sizing by tech-leads-club/agent-skills
npx skills add https://github.com/tech-leads-club/agent-skills --skill component-identification-sizing此技能用于识别代码库中的架构组件(逻辑构建块),并计算规模指标以评估分解可行性,识别过大的组件。
请求分析您的代码库:
示例 1:完整分析
User: "识别并评估此代码库中所有组件的规模"
技能将执行以下操作:
1. 映射目录/命名空间结构
2. 识别所有组件(叶节点)
3. 计算规模指标(语句数、文件数、百分比)
4. 生成组件清单表
5. 标记过大/过小的组件
6. 提供建议
示例 2:查找过大组件
User: "哪些组件过大?"
技能将执行以下操作:
1. 计算平均值和标准差
2. 识别大于 2 个标准差或超过 10% 阈值的组件
3. 分析大型组件内的功能区域
4. 提出具体的拆分建议及预估规模
示例 3:组件规模分析
User: "分析组件规模及其分布"
技能将执行以下操作:
1. 计算所有规模指标
2. 生成规模分布摘要
3. 识别异常值
4. 提供统计数据和推荐建议
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
在以下情况下应用此技能:
组件 是一个架构构建块,具有以下特征:
关键规则:组件由目录/命名空间结构中的叶节点识别。如果一个命名空间被扩展(例如,services/billing 扩展到 services/billing/payment),则父级成为子域,而不是组件。
语句数(非代码行数):
组件规模指标:
扫描代码库目录结构:
services/、routes/、models/、utils/
* 对于 Java:包结构(例如 com.company.domain.service)
* 对于 Python:模块路径(例如 app/billing/payment)services/BillingService/ 是一个组件
* 示例:services/BillingService/payment/ 扩展了它,使 BillingService 成为一个子域对于每个组件:
统计语句数 * 解析组件目录中的源文件 * 计算可执行语句(不包括注释、空行或单独的声明) * 汇总组件内所有文件的语句数
统计文件数
* 源文件总数(.js、.ts、.java、.py 等)
* 排除测试文件、配置文件、文档
计算百分比
component_percent = (component_statements / total_statements) * 100
计算统计信息
* 平均组件规模:total_statements / number_of_components
* 标准差:sqrt(sum((size - mean)^2) / (n - 1))
* 组件偏差:(component_size - mean) / std_dev
过大组件(拆分候选):
过小组件(合并候选):
规模适中的组件:
## 组件清单
| 组件名称 | 命名空间/路径 | 语句数 | 文件数 | 百分比 | 状态 |
| --------------- | ---------------------------- | ---------- | ----- | ------- | ------------ |
| Billing Payment | services/BillingService | 4,312 | 23 | 5% | ✅ 正常 |
| Reporting | services/ReportingService | 27,765 | 162 | 33% | ⚠️ 过大 |
| Notification | services/NotificationService | 1,433 | 7 | 2% | ✅ 正常 |
状态图例:
## 规模分析摘要
**总组件数**:18
**总语句数**:82,931
**平均组件规模**:4,607 语句
**标准差**:5,234 语句
**过大组件**(>2 个标准差或 >10%):
- Reporting (33% - 27,765 语句) - 考虑拆分为:
- Ticket Reports
- Expert Reports
- Financial Reports
**规模适中组件**(与平均值差距在 1-2 个标准差以内):
- Billing Payment (5%)
- Customer Profile (5%)
- Ticket Assignment (9%)
**过小组件**(<1 个标准差):
- Login (2% - 1,865 语句) - 考虑与 Authentication 合并
## 组件规模分布
组件规模分布(按占代码库百分比)
[如果可能,提供可视化表示或直方图]
最大:████████████████████████████████████ 33% (Reporting) ████████ 9% (Ticket Assign) ██████ 8% (Ticket) ██████ 6% (Expert Profile) █████ 5% (Billing Payment) ████ 4% (Billing History) ...
### 建议
```markdown
## 建议
### 高优先级:拆分大型组件
**Reporting 组件** (占代码库 33%):
- **现状**:单一组件,包含 27,765 条语句
- **问题**:过大,包含多个功能区域
- **建议**:拆分为:
1. Reporting Shared (通用工具)
2. Ticket Reports (工单相关报告)
3. Expert Reports (专家相关报告)
4. Financial Reports (财务报告)
- **预期结果**:每个组件约占代码库的 7-9%
### 中优先级:审查小型组件
**Login 组件** (占代码库 2%):
- **现状**:1,865 条语句,3 个文件
- **考虑**:如果与更广泛的身份验证相关,可能过于细化
- **建议**:评估是否应与 Authentication/User 组件合并
### 低优先级:监控规模适中组件
大多数组件规模适中。在分解过程中继续监控。
组件识别:
规模计算:
规模评估:
建议:
通常在以下位置找到组件:
services/ - 业务逻辑组件routes/ - API 端点组件models/ - 数据模型组件utils/ - 工具组件middleware/ - 中间件组件组件识别示例:
services/
├── BillingService/ ← 组件 (叶节点)
│ ├── index.js
│ └── BillingService.js
├── CustomerService/ ← 组件 (叶节点)
│ └── CustomerService.js
└── NotificationService/ ← 组件 (叶节点)
└── NotificationService.js
通过包结构识别组件:
com.company.domain.service - 服务组件com.company.domain.model - 模型组件com.company.domain.repository - 仓库组件组件识别示例:
com.company.billing.payment ← 组件 (叶包)
com.company.billing.history ← 组件 (叶包)
com.company.billing ← 子域 (payment/history 的父级)
JavaScript/TypeScript:
; 或换行符结尾的语句Java:
; 结尾的语句Python:
识别并评估组件规模后,创建自动化检查:
// 如果任何组件超过代码库的 10%,则发出警报
function checkComponentSize(components, threshold = 0.1) {
const totalStatements = components.reduce((sum, c) => sum + c.statements, 0)
return components
.filter((c) => c.statements / totalStatements > threshold)
.map((c) => ({
component: c.name,
percent: ((c.statements / totalStatements) * 100).toFixed(1),
issue: 'Exceeds size threshold',
}))
}
// 如果组件与平均值的差距超过 2 个标准差,则发出警报
function checkStandardDeviation(components) {
const sizes = components.map((c) => c.statements)
const mean = sizes.reduce((a, b) => a + b, 0) / sizes.length
const stdDev = Math.sqrt(sizes.reduce((sum, size) => sum + Math.pow(size - mean, 2), 0) / (sizes.length - 1))
return components
.filter((c) => Math.abs(c.statements - mean) > 2 * stdDev)
.map((c) => ({
component: c.name,
deviation: ((c.statements - mean) / stdDev).toFixed(2),
issue: 'More than 2 standard deviations from mean',
}))
}
完成组件识别和规模评估后:
每周安装量
60
代码仓库
GitHub 星标数
2.0K
首次出现
2026年2月7日
安全审计
安装于
opencode58
gemini-cli56
codex56
github-copilot56
cursor55
amp54
This skill identifies architectural components (logical building blocks) in a codebase and calculates size metrics to assess decomposition feasibility and identify oversized components.
Request analysis of your codebase:
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
Apply this skill when:
A component is an architectural building block that:
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.
Statements (not lines of code):
Component Size Indicators :
Scan the codebase directory structure:
Map directory/namespace structure
services/, routes/, models/, utils/com.company.domain.service)app/billing/payment)Identify leaf nodes
services/BillingService/ is a componentservices/BillingService/payment/ extends it, making a subdomainFor each component:
Count statements
Count files
.js, .ts, .java, .py, etc.)Calculate percentage
component_percent = (component_statements / total_statements) * 100
Calculate statistics
total_statements / number_of_componentssqrt(sum((size - mean)^2) / (n - 1))Oversized Components (candidates for splitting):
Undersized Components (candidates for consolidation):
Well-Sized Components :
## Component Inventory
| Component Name | Namespace/Path | Statements | Files | Percent | Status |
| --------------- | ---------------------------- | ---------- | ----- | ------- | ------------ |
| Billing Payment | services/BillingService | 4,312 | 23 | 5% | ✅ OK |
| Reporting | services/ReportingService | 27,765 | 162 | 33% | ⚠️ Too Large |
| Notification | services/NotificationService | 1,433 | 7 | 2% | ✅ OK |
Status Legend :
## 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%):
- Reporting (33% - 27,765 statements) - Consider splitting into:
- Ticket Reports
- Expert Reports
- Financial Reports
**Well-Sized Components** (within 1-2 std dev):
- Billing Payment (5%)
- Customer Profile (5%)
- Ticket Assignment (9%)
**Undersized Components** (<1 std dev):
- Login (2% - 1,865 statements) - Consider consolidating with Authentication
## Component Size Distribution
Component Size Distribution (by percent of codebase)
[Visual representation or histogram if possible]
Largest: ████████████████████████████████████ 33% (Reporting) ████████ 9% (Ticket Assign) ██████ 8% (Ticket) ██████ 6% (Expert Profile) █████ 5% (Billing Payment) ████ 4% (Billing History) ...
### 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.
Component Identification :
Size Calculation :
Size Assessment :
Recommendations :
Components typically found in:
services/ - Business logic componentsroutes/ - API endpoint componentsmodels/ - Data model componentsutils/ - Utility componentsmiddleware/ - Middleware componentsExample Component Identification :
services/
├── BillingService/ ← Component (leaf node)
│ ├── index.js
│ └── BillingService.js
├── CustomerService/ ← Component (leaf node)
│ └── CustomerService.js
└── NotificationService/ ← Component (leaf node)
└── NotificationService.js
Components identified by package structure:
com.company.domain.service - Service componentscom.company.domain.model - Model componentscom.company.domain.repository - Repository componentsExample Component Identification :
com.company.billing.payment ← Component (leaf package)
com.company.billing.history ← Component (leaf package)
com.company.billing ← Subdomain (parent of payment/history)
JavaScript/TypeScript :
; or newlineJava :
;Python :
After identifying and sizing components, create automated checks:
// Alert if any component exceeds 10% of codebase
function checkComponentSize(components, threshold = 0.1) {
const totalStatements = components.reduce((sum, c) => sum + c.statements, 0)
return components
.filter((c) => c.statements / totalStatements > threshold)
.map((c) => ({
component: c.name,
percent: ((c.statements / totalStatements) * 100).toFixed(1),
issue: 'Exceeds size threshold',
}))
}
// Alert if component is >2 standard deviations from mean
function checkStandardDeviation(components) {
const sizes = components.map((c) => c.statements)
const mean = sizes.reduce((a, b) => a + b, 0) / sizes.length
const stdDev = Math.sqrt(sizes.reduce((sum, size) => sum + Math.pow(size - mean, 2), 0) / (sizes.length - 1))
return components
.filter((c) => Math.abs(c.statements - mean) > 2 * stdDev)
.map((c) => ({
component: c.name,
deviation: ((c.statements - mean) / stdDev).toFixed(2),
issue: 'More than 2 standard deviations from mean',
}))
}
After completing component identification and sizing:
Weekly Installs
60
Repository
GitHub Stars
2.0K
First Seen
Feb 7, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode58
gemini-cli56
codex56
github-copilot56
cursor55
amp54
代码库搜索技能指南:精准查找函数、追踪依赖、理解架构与定位错误
10,900 周安装
BillingServiceCreate component inventory
(component_size - mean) / std_dev