Trigger Method
Triggered when the user executes /size-check or describes "simplify code" or "check file size".
Feature 1: Code Simplification (Original Capability)
Review the reusability, quality, and efficiency of changed code, and fix any issues found.
Check Items
| Check Item | Description |
|---|---|
| Duplicate Code | Extract common methods/components |
| Over-abstraction | Simplify unnecessary design patterns |
| Redundant Logic | Merge simplifiable conditional branches |
| Unused Code | Delete dead code and unused imports |
Feature 2: File Line Count Scan
Line Count Thresholds
| Language | Limit | Split Method |
|---|---|---|
| Java | 300 | Split Service responsibilities, extract Helper/Converter |
| Go | 400 | Split files in the same package by feature |
| Vue | 200 | Extract child components and composables |
| TSX/JSX | 200 | Extract child components |
| TypeScript/JS | 300 | Extract utility functions, constants, and types |
| Python | 300 | Split modules by responsibility |
Execution Flow
Full-project scan mode(when the user does not specify a file):
1. 扫描项目所有代码文件(排除 node_modules、vendor、dist、build、.git)
2. 统计每个文件行数,对照阈值标记超限文件
3. 检测 Markdown 文件中的重复章节(相同标题出现多次)
4. 输出超限清单 + 拆分建议
Single-file mode(when the user specifies a file):
1. 检查代码复用、质量、效率
2. 检查行数是否超限
3. 如果超限,给出具体拆分方案
Output Format
## 文件行数扫描结果
### 超限文件
| 文件 | 行数 | 阈值 | 超限 | 建议 |
|------|------|------|------|------|
| path/to/file.py | 450 | 300 | +150 | 按职责拆分为 xxx.py 和 yyy.py |
### 合规文件(前 10 个最大的)
| 文件 | 行数 | 阈值 | 余量 |
|------|------|------|------|
| path/to/big.go | 380 | 400 | 20 |
### 总结
- 扫描文件数:N
- 超限文件数:N
- 建议操作:[具体建议]
Scan Exclusion Rules
The following directories and files are not scanned:
- Directories:
node_modules/、vendor/、dist/、build/、.git/、__pycache__/、.venv/ - Files:
*.min.js、*.min.css、*.lock、*.sum - Config:
.toml、.json、.yaml、.yml(code line count limits do not apply to command/config files) - Documentation:
.md(Markdown has no hard line count limit, but duplicate sections are detected)
Feature 3: CSS Extraction Check
Trigger Condition
When scanning Vue/TSX/JSX files, detect inline <style> block line count.
Check Rules
| Check Item | Condition | Suggestion |
|---|---|---|
| Inline style too long | <style> block exceeds 30 lines |
Extract common styles to assets/styles/ |
| Non-scoped global styles | Exists in Vue SFC <style>(without scoped) |
Move to assets/styles/common.scss |
Not triggered:<style scoped> and component-level styles of ≤ 30 lines.
Output Format
Append to the file line count scan results:
### CSS 提取建议
| 文件 | <style> 行数 | 类型 | 建议 |
|------|-------------|------|------|
| src/views/User.vue | 45 | scoped | 提取公共部分(变量/mixin)到 assets/styles/ |
| src/views/Home.vue | 12 | 非 scoped | 移到 assets/styles/common.scss |
Fix Flow
After scanning, if over-limit files or CSS extraction suggestions are found, execute the following flow:
1. User Confirmation
Use AskUserQuestion to ask:
扫描发现 N 个问题(X 个文件超限 + Y 个 CSS 提取建议)。
是否修复?
1. 修复所有问题(推荐)
修复文件行数超限 + CSS 提取建议。改动后确保原有功能不受影响。
2. 跳过
不做任何修改,仅保留扫描报告。
If the user selects "Skip" → end.
2. Execute Fixes
Fix file by file, for each file:
- Read the complete file, understand the context and call relationships
- Check whether refactoring is involved:
- If table columns, data structures, or conditional branch modifications are involved, trigger the
refactor-safetyrule - Read the original code completely (do not rely on memory or speculation)
- Create a comparison checklist (columns/fields/config items)
- Verify consistency item by item (count/order/naming)
- If table columns, data structures, or conditional branch modifications are involved, trigger the
- Split/extract per scan recommendations:
- Line count over limit → split file
- CSS → extract to
assets/styles/
- Ensure the split entry files keep their original exports/interfaces unchanged
- Prioritize the files that most severely exceed the limit
Refactoring safety check:
- ✅ Table refactoring: number of columns, column names, and column order match the original code
- ✅ Data structure refactoring: fields are complete, nothing is missing
- ✅ Conditional branch refactoring: all if/else/switch branches have been handled
3. Verification
After the fix is complete:
- Check whether the project has a test command (
npm test/go test ./.../pytest, etc.) - Has tests → run tests, continue only if all pass
- No tests → output a change list, prompt the user to verify manually
4. Self-review
Automatically run /review quick to quickly review the fix content.
Safety principles
- Report first, fix after confirmation — scan results require user confirmation before fixes are performed
- Do not change existing behavior — split entry files keep their original interfaces
- Progressive handling — prioritize the files that most severely exceed the limit
Rule traceability
> 📋 本回复遵循:`size-check` - [功能1/功能2/功能3]