impact

GitNexus 影响分析

仅限 CLI——不存在 MCP 服务。切勿对 gitnexus:// URI 使用 readMcpResource。

分析修改某个符号的影响范围——哪些对象会调用它、它参与哪些流程，以及哪些测试覆盖了它。

自我演进的技能：此技能会在使用过程中不断改进。如果指令有误、参数发生变化，或需要变通方案，请立即修复此文件，不要拖延。仅针对真实且可复现的问题进行更新。

使用时机

• 修改调用者众多的函数之前
• “如果我修改 X，会有什么地方出问题？”
• “修改 Y 是否安全？”
• “修改 Z 的影响范围有多大？”

工作流

步骤 0：预检——确保 CLI 可调用

gitnexus 二进制文件通过 npm/mise 安装。如果当前项目中未启用 node，mise shim 可能会失效。在执行任何 gitnexus 命令前，先运行此预检：

# Test if gitnexus is actually callable (not just a broken shim)
gitnexus --version 2>/dev/null || mise use [email protected]

以下所有命令均从仓库根目录运行。如果工作区中索引了多个仓库，请添加 --repo <repo-name> 指定目标。否则，--repo 为可选项。

步骤 1：如果索引过期，则自动重新索引

gitnexus status

如果索引过期（索引的提交 ≠ HEAD），请在继续之前自动重新索引——不要询问用户：

gitnexus analyze

然后重新检查状态，确认索引已是最新。

步骤 2：上游影响范围

gitnexus impact "<symbol>" --depth 3

这会显示所有依赖此符号的对象（调用者，以及深度最多为 3 的传递调用者）。

如果返回了多个候选项，请消除歧义：

gitnexus impact "<symbol>" --uid "<full-uid>" --depth 3
# or
gitnexus impact "<symbol>" --file "<file-path>" --depth 3

步骤 3：下游依赖（可选）

gitnexus impact "<symbol>" --direction downstream --depth 3

显示此符号依赖的对象——有助于了解依赖项是否可能发生变化。

步骤 4：测试覆盖

gitnexus impact "<symbol>" --include-tests

显示哪些测试文件会执行此符号。

步骤 5：风险评估

根据直接依赖对象的数量：

依赖对象数	风险级别	建议
< 5	低	进行基本测试后即可安全修改
5–20	中	检查所有调用者，并运行相关测试
20–50	高	考虑保持向后兼容的 API，并进行全面测试
50+	严重	需要弃用策略和分阶段迁移

步骤 6：结构化报告

提供以下内容：

• 风险级别及依赖对象数量
• 受影响最大的流程——包含此符号的执行流程
• 直接调用者——直接调用此符号的函数/方法
• 测试覆盖——会执行此符号的测试（或覆盖缺口）
• 建议——可安全修改、需要测试，或需要迁移计划

示例

用户：“如果我修改 RangeBarProcessor，会有什么地方出问题？”

gitnexus impact "RangeBarProcessor" --depth 3
gitnexus impact "RangeBarProcessor" --include-tests

输出：“风险严重——12 个流程中有 73 个依赖对象。8 个测试文件覆盖了它。建议仅进行向后兼容的修改。”

执行后反思

此技能执行完毕后，在结束任务之前进行反思：

0. 确定自身位置。——找到此 SKILL.md 的规范路径，然后再进行编辑。
1. 哪里失败了？——修复导致问题的指令。
2. 哪些地方比预期更有效？——将其提升为推荐实践。
3. 哪些内容发生了偏差？——修复不再符合实际情况的脚本、引用或依赖项。
4. 记录下来。——添加演进日志条目，记录触发原因、修复内容和证据。

不要拖延。下次调用时，会继承你留下的一切。