审查特性分支
审阅功能分支时，以约定基线、项目规则和预期行为为依据。将规范问题与需求缺失或实现错误分别记录，并把每项发现对应到相关修改行。这样作者能够区分代码约定与功能后果，按问题本身安排修复。
Code Review by Matt Pocock
使用 Matt Pocock 的 Code Review，对照指定 Git 基准审查分支。分别检查仓库规范与原始需求，并列查看带有代码位置的问题，避免将符合规范误当作需求已经完整实现。
对照需求审查实现差异
指定固定比较点和修改需要满足的要求，将审阅请求区分为规范检查与行为缺口。发现应关联相关差异及证据，而不是只给出笼统的代码质量印象，方便随后决定具体修复。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: Code Review https://github.com/mattpocock/skills/blob/main/skills/engineering/code-review/SKILL.md 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 使用 Matt Pocock 的 Code Review 对照 main 审查分支，需求文件是 docs/specs/import.md，分别报告规范与需求发现。 期望交付: 分别报告规范与需求问题，并关联相关修改行。
关于 Code Review
Code Review 是 Matt Pocock 工程集合中的双轴审查 Skill。它先解析比较参考，确认基于合并基点的差异非空，再查找原始需求与仓库编码规范。两个独立子代理分别检查规范和需求覆盖，最终报告保留两方面发现。规范轴还使用有明确标识的代码异味基线，但项目文档中的约定具有优先权。没有需求说明时，会明确跳过需求轴，而不是自行编造。使用需要可访问的 Git 历史、预期比较点及集合的需求跟踪配置；它提供审查流程，不会自动批准修改，也不保证完成问题修复。
Code Review Skill的使用场景
分支规范、任务单要求和发布范围，需要各自清楚的比较基线。Code Review 将发现对应到固定版本、相关差异和支持证据，让审阅者能够区分风格问题、缺失行为与范围遗漏。
核对工单实现
核对任务单实现时，将验收条件与代码差异及相关测试逐项对照。查找缺失、只完成一部分或偏离规格的行为，并为每种状态提供证据。不能只凭分支整体看起来已经完成，就代替具体要求之间的比较。
复核发布差异
版本审计需要固定发布标签、目标提交和排除范围。检查差异时保持这些参照稳定，让其他审阅者能够复现相同范围。后续尚未发布的修改不混入本次结论，避免移动中的分支静默扩大审阅内容。
在缺少规格时审阅代码
仓库修改可能已有清楚的比较点，却没有可供核对的原始规格。按已记录项目标准审阅，并明确说明规格轴已经跳过，不为填补缺口自行编造验收条件。报告应区分哪些结论来自代码约定，哪些需求因材料缺失而无法评估。
如何审查分支变更
审阅范围需要由固定 Git 比较点和原始要求共同确定。收集仓库约定后，分别检查不同审查轴，逐项核实发现，再决定修复和补充测试，避免把印象直接写成缺陷。
固定比较点
提供有效提交、分支或标签，并确认合并基点差异覆盖目标工作。
提供规范与需求
指出仓库约定与原始需求；缺少需求说明时明确记录。
分别核对两组结果
独立阅读规范和需求发现，不把某一轴通过当作另一轴也合格。
探索更多 Agent Skills
查看其他 Skill 指南，并在使用前核对原始来源。
Code Review 常见问题
流程使用哪种 Git 比较？
它使用所选参考与 HEAD 的三点比较，基于二者合并基点审查。应先确认该范围符合目标。
参考无效或差异为空怎么办？
原文在分发审查前检查这些条件。应修正比较范围，而不是把空审查视为成功评估。
必须提供需求说明吗？
它会尝试查找原始工单或说明。没有时应明确报告并跳过需求轴，而不是猜测要求。
哪些编码规范优先？
仓库文档规范优先于通用代码异味基线。异味属于判断线索，不自动等于硬性违规。
没有子代理的宿主能原样运行吗？
原始流程使用并行子代理来分离审查上下文。顺序审查属于适配方式，与原流程的执行结构不同。
为什么不把两个轴的结果合并？
符合规范的代码可能漏需求，行为正确的代码也可能违背项目约定。分开报告可以保留不同问题。
如何配置需求跟踪方式？
集合中的 setup-matt-pocock-skills 配置 Skill 会记录仓库需求跟踪方式。工程使用前应先配置，以便审查找到正确来源。