change-impact-analysis

变更影响分析

适用场景

• 当你需要根据代码、配置、数据和依赖项的变更，识别受影响的能力、回归范围和发布风险时，使用此技能。
• 使用此技能审查现有计划、结果或证据集，并提出可执行的改进建议。
• 当上下文不完整，但仍可进行有界的初步分析时，使用此技能。

输出格式选项

• 默认使用 Markdown 进行审查、执行和迭代改进。
• 当用户要求表格、CSV、JSON 或工单字段时，保留风险、证据、优先级和边界信息。
• 对于机器读取的输出，请先确认架构、枚举值和必填字段。

使用方法

1. 阅读并遵循 prompts/change-impact-analysis.md，包括其输入约定、执行规则、最低覆盖范围和输出顺序。
2. 仅补充会影响决策的上下文：范围、环境、版本、约束、证据和成功标准。
3. 审核输入，然后区分已确认事实、工作假设和待解决问题。
4. 按风险和证据强度排序，并生成可直接执行或审查的产物。
5. 如果信息缺失，请提供有界的初步分析，并说明哪些结论缺乏依据。

参考文件

• 校准领域结果、有效控制项或证据缺口时，请阅读 references/domain-decision-example.md，了解经过脱敏的输入、逐项判定依据和可复现的计算。

• 始终阅读 prompts/change-impact-analysis.md；它是此技能的完整执行规范。

• 进行评估或回归时，请阅读 evals/eval.yaml 和 evals/cases/ 下的相关案例。

• 仅当这些目录存在且任务需要时，才加载 references/、examples/、scripts/ 或 output-formats.md。

领域执行要点

1. 确定变更版本和范围，并构建带类型的“变更文件/符号/配置→依赖项→业务义务→测试 ID”证据边，标注来源/版本以及已确认/候选/未知状态。
2. 遍历直接和传递消费者，并通过去重处理循环。仅在有证据证明契约隔离或不存在消费者的边界处停止，并记录原因；目录本身不构成边界。
3. 动态注册、运行时配置或未追踪的依赖项仍属未知。根据风险提出消费者契约/集成检查；缺少映射并不意味着没有影响。
4. 说明纳入/排除依据、最低验证要求、剩余风险和扩展触发条件。此技能广泛覆盖代码/数据/配置变更；针对 PR 的配套技能负责管理基础版本/目标版本/差异的身份信息。

核心约束

• 区分已确认的影响和推断的影响。
• 不得仅根据变更文件选择测试。
• 将无法追踪的依赖项标记为风险。
• 切勿编造证据中不存在的系统行为、字段、数据、指标或根因。
• 重要结论须关联证据；对缺乏依据的结论，应标记为假设并说明验证方法。
• 根据业务影响、发生可能性或可检测性解释优先级。

交付清单

• 已覆盖：直接影响、传递影响、数据兼容性、API 契约、权限、运行时依赖项、回滚、可观测性。
• 已区分事实、假设、缺口和建议。
• 为高风险事项指定了优先级、证据依据、负责人或后续行动。
• 定义了可验证的决策标准，而非泛泛而谈的建议。
• 未执行未经授权的生产环境写入或破坏性操作。

常见问题

• 列出检查项，却未说明前置条件、预期结果或证据。
• 将所有事项都标为高优先级，回避权衡。
• 用工具名称或泛泛而谈的理论替代领域分析。
• 拒绝处理不完整的输入，或假装不完整的证据足以支持确定结论。

最佳实践

• 优先检查最可能导致业务损失、安全问题或发布受阻的路径。
• 通过最小且可验证的实验降低不确定性，并记录复现条件。
• 确保产物可执行，且另一位工程师能够独立审查。