用途：在实施代码改动前做结构化的影响分析，避免意外副作用、破坏性变更与不一致模式。优先级为风险意识、依赖理解与受控变更，而非速度。它本身不写代码。
主要能力与流程： 1）先定义范围：说明改什么、在哪、为何；识别受影响的入口（文件、模块、API）；分类改动类型（重构、重命名、API 变更、行为变更、删除）。范围不清时要求补充细节，不得凭假设推进。 2）追踪依赖（纵向影响）：按 L0 被改文件、L1 直接依赖方、L2 传递依赖方、L3 系统级或共享模块影响逐层映射，至少追到 L2，共享/核心模块追到 L3。破坏性变更分级：CRITICAL（API 移除、schema 变更）、HIGH（函数签名变更）、MEDIUM（行为变更）、LOW（仅内部）。 3）一致性检查（横向影响）：对照命名约定、文件结构、API 设计、类型用法，标出偏离程度（HIGH 破坏既有约定、MEDIUM 与同类模块不一致、LOW 细微差异）；只报告不一致，不静默统一模式。 4）评估影响半径：统计受影响文件数、涉及模块或服务、跨边界效应。信号：≥10 文件为中风险，≥15 文件为高风险并建议拆分 PR；共享/核心模块影响放大；多服务存在级联风险。追问“这个涟漪会扩散多远”“还有什么会间接受影响”。 5）检测级联效应：关注模块间顺序失败、组件间反馈回路、共享资源争用（数据库、队列、缓存）、时序/顺序问题（异步流程）；在改动涉及多模块/服务、依赖双向、风险非局部时触发。 6）风险评分（1–10）：按范围 30%、破坏潜力 25%、模式偏离 20%、测试覆盖 15%、可逆性 10% 加权。1–3 低、4–6 中、7–8 高（需缓解）、9–10 严重（阻断或重新设计）；须说明打分理由。 7）给出建议：GO 可继续、CONDITIONAL GO 需缓解措施、NO-GO 风险过高需重新设计；并列出必要防护、测试需求与回滚考虑。
用法示例（按资料）：用户要求“重命名一个共享 API 方法”时，识别所有调用方（L1、L2），判定为 HIGH 破坏性变更，评估受影响文件（如 12 个），标记高风险，并建议增加向后兼容层、增量更新调用方、补充回归测试。
预期表现：编码前识别风险、显式映射依赖链、现实地界定改动范围、尽早暴露隐藏影响、挑战大型或高风险改动。
限制：资料未提供安装方式、价格、平台支持、运行环境等信息，暂未提供；该技能不编写代码。