| name | code-review-change |
| description | 分析指定改动的上下游影响，追踪调用链，发现潜在缺陷和隐患。仅当用户明确说出"使用 code-review-change"或"启动 code-review-change"时触发。不适用于任何隐式场景。 |
改动影响分析
分析指定改动的上下游影响，追踪调用链，发现潜在缺陷和隐患。只发现问题，不自动修复。
触发约束
此 skill 仅通过显式调用触发。
⛔ 不触发的场景
- 用户提到"检查改动"、"看看影响"等但未提及 code-review-change
- 完成 Edit/Write 后的自动检查
- 用户未显式引用 @code-review-change
✅ 触发条件
必须同时满足：
- 用户明确说出"使用 code-review-change"或"启动 code-review-change"，或显式引用 @code-review-change
- 用户提供了改动范围（文件、函数、类）或明确需求
核心原则
- 只找不改 — 只发现问题并报告，不自动修复任何问题
- 双向追踪 — 既向上找调用者，也向下找被调用者
- 全局视角 — 放在整个项目上下文中评估影响范围
执行流程
Step 1: 确认改动范围
确认用户要分析的改动：
- 文件路径（如
src/utils/parser.py）
- 函数/类名（如
parse_config()、ConfigLoader）
- 改动类型（新增、修改、删除、重构）
如果用户未明确指定，询问确认。
Step 2: 向上追踪（调用者）
找出所有调用被修改对象的代码：
对于函数/方法：
- 使用 LSP
findReferences 或 grep 搜索调用点
- 检查每个调用点：
- 参数传递是否匹配新签名
- 返回值使用是否匹配新返回类型
- 错误处理是否覆盖新增的异常
对于类/模块：
- 搜索 import 语句
- 检查实例化点
- 检查继承/依赖关系
Step 3: 向下追踪（被调用者）
找出被修改对象内部调用的代码：
对于函数/方法：
- 使用 LSP
outgoingCalls 或阅读函数体
- 检查：
- 被调用函数的接口是否稳定
- 数据流是否产生新依赖
- 副作用是否影响外部状态
对于类/模块：
Step 4: 影响分析
综合上下游信息，分析潜在问题：
| 问题类型 | 检查点 |
|---|
| 接口不兼容 | 新增参数是否所有调用者都传递了 |
| 类型不匹配 | 返回类型变更是否所有调用者都能处理 |
| 数据流断裂 | 删除的中间函数是否阻断数据流 |
| 状态污染 | 新增的副作用是否影响共享状态 |
| 性能退化 | 新增的调用链是否引入性能瓶颈 |
| 循环依赖 | 新增的依赖是否形成循环 |
Step 5: 输出报告
输出结构化报告：
## 改动影响分析
**改动对象**: {文件路径}:{函数/类名}
**改动类型**: {新增/修改/删除/重构}
### 上游调用者（X 个）
| 调用点 | 文件:行号 | 风险 |
|--------|----------|------|
| {调用者1} | `path:123` | 🟡 参数数量不匹配 |
| {调用者2} | `path:456` | ✅ 无风险 |
### 下游被调用者（X 个）
| 被调用对象 | 文件:行号 | 稳定性 |
|-----------|----------|--------|
| {函数A} | `path:789` | ✅ 接口稳定 |
| {函数B} | `path:321` | ⚠️ 有 pending refactor |
### 潜在问题
#### 🔴 [接口不兼容] {描述}
- **位置**: `path/to/file.ext:行号`
- **问题**: ...
- **建议**: ...
#### 🟡 [数据流断裂] {描述}
- **位置**: `path/to/file.ext:行号`
- **问题**: ...
- **建议**: ...
### 影响范围摘要
- 直接影响文件：X 个
- 间接影响文件：Y 个（通过调用链传播）
- 需同步修改：Z 个文件
反模式
- 禁止只检查被修改文件本身 — 必须追踪上下游
- 禁止自动修复任何问题 — 只报告
- 禁止跳过 LSP/grep 工具直接"凭经验判断"
- 禁止遗漏调用链中的中间节点 — 递归追踪直到叶子或风险可控
完成检查清单
标记分析完成前确认：
