软件工程
为代码审查准备一项变更
小型、好懂的变更请求：行为已验证，审查脉络与已知风险都写明白。
流程
按这个顺序做。
- 重述预定用户或系统成果，并把差异对照该范围。
- 在文件和系统上下文中审阅每行变更的设计契合、正确性、安全、并发和可避免复杂度。
- 检查测试能否因损坏行为失败、覆盖相关边界情况，并匹配变更风险级别。
- 运行仓库要求的格式、静态检查、类型检查、测试、构建和文档生成。
- 去掉附带变更、生成噪音、调试输出、死代码和密钥；若无法连贯审阅则拆分变更。
- 写拉取请求摘要，覆盖为何、什么、核验证据、相关时的截图或迁移说明、风险和回滚。
先准备
猫会向你要的输入。
- 变更分支或差异
- 议题或验收标准
- 仓库贡献与测试说明
路由器 + 一份 playbook
先路由。只选一份。
Cat Paw 每次任务只加载一份 playbook，不合并多份。先走这个路由器；其余路径是此 workflow 可检查的候选。
- 路由器：
engineering-pack skills/engineering/mattpocock/code-review/SKILL.md
界限
界限跟着提示一起走。
- 未经执行不要声称检查已通过。
- 不要在差异或证据中暴露凭证、令牌或个人数据。
- 把安全、隐私、无障碍或并发等专业领域升级给合格审阅人。
完成代表
一个可核对的终点。
差异范围清晰可解释，所需本地检查通过，审阅产物完整，且无未解决的高严重性自审发现。
来源
这个流程从哪来。
- google.github.io/eng-practices/review/reviewer/looking-for.html
- google.github.io/eng-practices/review/developer/small-cls.html
来源确立 workflow 的模式。如有 Reddit 或社区帖子，视为实务轶事，不是普遍事实。
