用途：在实现和针对性验证完成后，检查完整 diff，识别受影响的已发布包，判断变更是否属于消费者可见变更，并决定是否需要创建 changeset。
主要能力：分类影响范围，包括源码类型、运行时行为、入口点、必需服务、生命周期、持久化或线格式数据；执行破坏性审计；记录无需 changeset 的理由，或产出一份连贯的 changeset；校验包名、frontmatter、版本提升策略和面向消费者的文本。
需要创建 changeset 的情形：可观察的运行时行为变更（含缺陷修复）；导出的值或公共类型变更；入口点或导出映射变更；必需服务、错误、所有权、默认值或生命周期变更；持久化、序列化、协议或线格式变更。通常不需要的情形：仅测试变更、保持行为的内部重构、文档或 JSDoc 维护、未发布的工具。不确定时应检查导出和消费者可见声明，而非根据源码位置推断。
破坏性审计：当现有有效消费者代码、配置或数据必须修改才能继续编译或按原契约运行时，该变更即为破坏性。需审计名称与位置、调用兼容性、结果兼容性、运行时契约、数据兼容性等所有表面。新增导出、可选参数、保持行为的实现通常非破坏性；恢复文档化契约的修复通常非破坏性，但若其运行影响对消费者可见，仍需 changeset。当重载顺序、结构可赋值性或推断使兼容性不确定时，应验证代表性现有调用。API diff 输出是机械证据，不是语义化版本决策。
使用方式：检查完整 diff，识别直接受影响的已发布包；分类影响；执行破坏性审计；记录无需 changeset 的理由或一份连贯 changeset；需要时阅读 authoring.md；校验包名、frontmatter、版本提升策略和消费者文本；不要包含无关的工作区变更。
完成标准：每个受影响表面和已发布包都已说明，且要么明确无需 changeset 的决定，要么有一份连贯、有效的 changeset 描述每个破坏点的消费者影响与迁移。
限制：资料未提供具体安装命令、平台支持、收费或价格信息。