该技能面向代码或产品交付前的多来源问题汇总。输入为用户点名的每份报告，默认还包括 .scratchpad/<slug>/ 下所有 *-report.md；每份报告分配一个简短来源标签，例如 V 表示规格验证、B 表示浏览器测试、RT 表示红队、P 表示生产就绪。
构建清单时先做去重：同一项变更可能同时修复多份报告中的问题，合并后保留全部来源标签与编号，如 (RT2, B1)。每条变更须写成可执行动作而不是问题描述，例如写“在订单列表中为长单词换行”，而不是“长单词破坏布局”。随后结合交通灯标记确定灯色，保留证据支持的最高灯色。
清单按时机分组：🔴 合并前必须处理；🟠 合并前建议处理（改动代码少）；🟠 上线前处理；🟠 技术债；🟡 小改进；已接受不改并说明原因。在该顺序下将变更编号 1..N，这些编号是用户批准工作的依据，分享后不得改动。每条变更包含编号、灯色、行动、简短原因、主要文件与来源标签。
输出方面，清单保存到 .scratchpad/<slug>/change-list.md；在对话中展示紧凑列表，每条一行，含编号、灯色、行动与来源。随后询问用户要应用哪些变更，并建议默认选择：全部 🔴 加上成本低的合并前 🟠。获批准后，使用 execute-plan-loop 的 change-list 模式应用所批准的变更。
适用场景为多份检查报告需要统一整理、排序并形成可批准执行清单时。限制：资料未提供独立安装命令、收费方式或具体平台要求；执行依赖资料中提到的报告文件结构、交通灯标记与 execute-plan-loop 机制。