用途
依赖关系分析（Dependency Map）用于在代码改动之前，回答"改这里会影响哪里"的问题。代码改动最怕的不是改错，而是不知道改动波及到了哪里。本 skill 的使命是在改动之前，画出影响面地图。它追踪调用链、数据流、副作用，评估改动的影响面。
与其他 skill 的关系：code-walkthrough（理解代码）→ dependency-map（评估影响）→ refactoring（执行改动）。
dependency-map 与 code-walkthrough 的区别：walkthrough 关注理解代码，回答"这段代码是什么，怎么运转"；dependency-map 关注评估影响，回答"改这里会动到哪里"。通常先 walkthrough 建立理解，再 dependency-map 评估改动。
主要能力
第一步：确定分析目标
用 AskUserQuestion 确认：
- 分析什么：哪个函数/类/模块/文件？
- 为什么分析：准备改什么？删什么？还是纯了解？
- 分析深度：只看直接依赖，还是追踪到底？
不同分析请求对应不同追踪方向：
- 改函数签名 → 追踪所有调用方
- 改数据结构 → 追踪数据的读写点
- 删文件/模块 → 追踪所有 import
- 改 API 接口 → 追踪前端调用 + 外部消费方
- 改配置/环境变量 → 追踪所有引用点
第二步：静态依赖分析
2.1 Import/Require 分析，用于找到谁引用了目标文件。示例命令：
grep -r "import.*from.*'目标模块'" src/
grep -r "require('目标模块')" src/
或用 Grep 工具搜索。输出包含"被谁引用（上游，改目标会影响他们）"和"引用了谁（下游，目标依赖他们）"。
2.2 函数/方法级调用链，追踪更精细的调用关系。示例命令：
grep -rn "目标函数名(" src/ --include="*.ts" --include="*.js"
输出包含调用链的定义位置、调用方，以及影响面评估。
第三步：数据流分析
当改动涉及数据结构时，追踪数据从哪来、到哪去。针对数据结构变更，输出其定义位置、创建点（写入）、读取点、持久化位置，并进行影响评估。例如给类型加字段时，需考虑数据库 migration、缓存序列化/反序列化兼容、API 响应是否自动包含；删字段时需检查所有读取点是否还在用、前端是否依赖该字段。
第四步：输出影响面评估
4.1 影响面清单，包括：
- 直接影响（必须改）：标注文件、行号、影响原因、改动类型
- 间接影响（需要验证）：标注文件、行号、风险点、验证方式
- 不受影响（确认安全）
- 测试影响
4.2 风险等级：
- 低风险：只影响内部实现，公共接口不变，有测试覆盖
- 中风险：影响多个文件但不影响外部接口，有部分测试覆盖
- 高风险：影响公共接口/全局中间件/数据结构，测试覆盖不足
分析准则
- 宁多不漏：不确定的归入"需要验证"，不要归入"不受影响"
- 标注行号：每个影响点必须标注具体位置，方便定位
- 区分直接/间接：直接影响必须改，间接影响需验证，不要混在一起
- 关注隐式依赖：不只看 import，还要看运行时依赖（事件监听、全局状态、环境变量）
- 递归但有界：追踪调用链要有深度限制，一般追 3 层足够，超过 3 层的间接影响可忽略
使用方式
通过触发词唤起该技能，触发词包括：影响面、改这个会影响哪里、依赖关系、调用链、影响分析、谁在用这个。唤起后按上述四步流程进行：确认分析目标、静态依赖分析、数据流分析、输出影响面评估。
适用场景
适用于在修改函数签名、修改数据结构、删除文件/模块、修改 API 接口、修改配置/环境变量之前，需要评估改动影响面的场景。也适用于单纯想了解某段代码的依赖关系。
限制
关于该技能的具体平台支持范围、配置要求、安装方式等信息，资料暂未提供。追踪调用链一般限制在 3 层深度，超过 3 层的间接影响可忽略。