cc-size-check

Size Check - Code simplification and file line count check

Trigger method

Triggered when the user executes $cc-size-check or $size-check or describes "simplify code" or "check file size".

---

Feature 1: Code simplification (existing 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	Splitting method
Java	300	Split Service responsibilities, extract Helper/Converter
Go	400	Split files in the same package by function
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 included in the scan:

• Directories:node_modules/、vendor/、dist/、build/、.git/、__pycache__/、.venv/
• Files:*.min.js、*.min.css、*.lock、*.sum
• Configuration:.toml、.json、.yaml、.yml(code line count limits do not apply to command/configuration files)
• Documentation:.md(Markdown has no hard line count limit, but duplicate sections are detected)

---

Feature 3: CSS extraction check

Trigger conditions

When scanning Vue/TSX/JSX files, detect the line count of inline <style> blocks.

Check rules

Check item	Condition	Suggestion
Inline styles too long	<style> block exceeds 30 lines	Extract common styles to assets/styles/
Non-scoped global styles	Vue SFC contains <style>(without scoped)	Move to assets/styles/common.scss

Not triggered：<style scoped> and component-level styles with 30 lines or fewer.

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 the scan is complete, 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:

1. Read the complete file, understand the context and call relationships
2. Check whether refactoring is involved：
   • If it involves modifications to table columns, data structures, or conditional branches, trigger the cc-refactor-safety rule
   • Read the original code completely (do not rely on memory or inference)
   • Create a comparison checklist (columns/fields/configuration items)
   • Verify consistency item by item (count/order/naming)
3. Split/extract as per scan recommendations：
   • Line count exceeds limit → split file
   • CSS → extract to assets/styles/
4. Ensure the entry file after splitting keeps its original exports/interfaces unchanged
5. Prioritize the files most severely over the limit

Refactoring safety check：

• ✅ Table refactoring: column count, 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:

1. Detect whether the project has a test command (npm test / go test ./... / pytest , etc.)
2. Has tests → run the tests, continue only if all pass
3. No tests → output a change list and prompt the user to verify manually

4. Self-review

Automatically run /review quick to perform a quick review of the fix content.

---

Safety principles

• Report first, fix after confirmation — scan results require user confirmation before fixes are executed
• Do not change existing behavior — the entry file after splitting keeps its original interfaces
• Progressive handling — prioritize the files most severely over the limit

---

Rule traceability

> 📋 本回复遵循：`size-check` - [功能1/功能2/功能3]