用途：在开始代码审查前，判断改动属于小改动还是大改动，以确定审查范围。核心原则是大改动需要更广的审查，小改动只需聚焦审查。
小改动：只审查新代码。特征为改动文件少（1-3 个）、改动孤立、无 API 变化、无新依赖、影响局部。示例包括单函数缺陷修复、给已有模型加字段、小功能、更新常量或配置、修正错别字。审查范围为改动行、新测试及直接函数上下文。
大改动：审查新代码和受影响代码。特征为改动文件多（4 个以上）、跨模块、公共 API 变化、新增依赖、行为变化、架构影响。示例包括跨多文件的新功能、核心模块重构、修改认证流程、新增服务层、修改数据库结构。审查范围包括所有改动代码、所有调用改动代码的代码、被改动代码调用的代码、集成点与端到端流程。
决策流程：改动文件是否超过 3 个，是则为大改动；否则检查公共 API 是否变化，是则为大改动；否则检查行为是否变化，是则为大改动，否则为小改动。
查找受影响代码：可用 grep -r "import.from.'./changed-module'" src/ 查找导入者，grep -r "changedFunction" src/ 查找函数使用处，用 grep "import" src/changed-file.ts 查看依赖，并沿调用链向上向下追溯。
审查前应记录范围：小改动列出改动文件、审查重点与不审查内容；大改动列出改动文件、受影响代码、集成点与审查重点。检查清单在小改动基础上，大改动还需确认调用者、被调用者、集成点、端到端流程与受影响测试。
边界情况：不确定时默认按大改动处理；少量代码也可能有大影响（如修改默认超时常量），需审查所有受影响代码；大量文件但纯重构仍属大改动，结构审查为主但行为审查较轻。该技能由 issue-driven-development 第 9 步和 comprehensive-review 在审查前调用，用来确定审查多少代码、检查哪些测试和集成点。
限制：资料未说明该技能的安装方式、运行平台、收费情况与实际效果。