Analyzing Changes

变更校验关卡

看清「改了什么、影响哪里、文档是否跟上」——是变更的体检，不是审查替代品。

何时使用

场景	跑	判据
提交前（任何代码改动）	✅	默认门禁
重构完成	✅	评估辐射面
设计级改动	✅	DESIGN.md 是否同步
PR review	✅	替代手工 diff 计数
跨模块大改	✅	看依赖图是否成环
紧急 hotfix	⚠	跑，但允许文档同步延后到稳定后

三种模式

模式	时机	用途
working (默认)	写代码过程中	自检，看「我现在的工作面有哪些待整理」
staged	git add 后、commit 前	提交闸，看「这一 commit 的合理性」
committed	commit 完成后	review，看「上一段历史改了哪些范围」

警告判定

警告	触发	处置
代码 >50 行 而 DESIGN.md 未更新	设计层面变化未留痕	补 DESIGN.md「改了什么/为何」段
代码 >30 行 而无测试更新	测试覆盖滞后	补单测/集成测；或在 PR 注明「该路径已有 E2E 覆盖」
新增文件而 README.md 未更新	用户视角文档滞后	补模块入口说明
配置变更未记录	部署可能踩坑	CHANGELOG / DESIGN 留迁移说明
删除文件	引用可能未清理	全仓 grep 文件名/导出符号

解读输出

工具产出三类信号：

1. 文件分类 — 自动分代码/文档/测试/配置；用于判断「是否纯文档变更」
2. 模块识别 — 把变更聚到模块边界；用于判断「跨模块改动」
3. 影响评估 — 行数 + 文件数；用于判断「改动是否需要拆 PR」

拆 PR 的判据（基于 commit 角度）：

• 跨 ≥3 模块且无统一主题 → 拆
• 单 commit >500 行非生成代码 → 拆
• 一次同时改架构 + 实现 + 文档 → 通常合理（同主题）

与其他 skill 联动

• 设计级变更 → 触发 verifying-modules 看新模块文档完整性
• 安全相关变更 → 触发 analyzing-security
• 重构 → 触发 checking-code-quality 防退化

使用

node scripts/change_analyzer.js                   # working（默认）
node scripts/change_analyzer.js --mode staged     # 暂存区
node scripts/change_analyzer.js --mode committed  # 已提交
node scripts/change_analyzer.js -v                # 详细
node scripts/change_analyzer.js --json            # CI 用

人工复核

工具给信号，人下结论。先读受影响模块 README/DESIGN，确认：

• 职责边界是否仍清晰
• 设计决策是否仍成立
• 测试是否覆盖新路径

设计级改动须于 DESIGN.md 留痕：改了什么、为何改、影响何处。三段缺一不可。