walk-pr

逐步引导用户审查 PR 或大型差异：每次处理一个子变更集（SC）——一组彼此相关的文件；并且每次只讨论其中一个审查主题。

输入 = PR 编号、PR URL、差异范围，或不提供任何内容（推断当前分支对应的 PR；如果没有，则回退到与仓库实际的远程跟踪默认分支进行比较）。

读者模型。 审查者熟悉仓库，但对这个 PR 完全不了解。代码库中的词汇是双方的共同基础；PR 引入的词汇则不是——新类型、模式、模块和领域术语必须先明确介绍，再用于后续内容。

注意力约定。 此技能的所有模式都遵循同一约定：先提供高层概览，每次只聚焦一个想法，并且只有在审查者提出要求时才深入探讨——包括理由、代码、差异和长文本。在聊天中，这体现为下文的一次一个 SC、一次一个主题；在画布中，则体现为一张视觉地图，所有文字内容都收在可点击展开的部分后面。每当需要选择呈现方式时，都要避免信息墙：呈现给审查者的内容不得超出当前想法所需。

先提供概览。 在变更概览之前，先提供 PR 简介：用工作流术语写一段问题陈述；只有在确实有助于理解时，才提供概念术语表（工作流层面的定义，而非类型签名）、组件示意图或阅读提示。然后按类别概述变更（先列出关键变更，再列出脚手架／数据变更）；差异很简单时，略过这两部分。

每个子变更集，按需深入。 每个 SC 始终可见的内容是一句行为摘要（用户会看到什么变化）和一句验证探查（如何观察并确认其正常工作）。其他所有内容——边界视图、主题、差异——都是需要时才展开的深入内容；只针对确有必要的 SC 展开。

深入内容——先看边界。 先提供简短的边界视图，让审查者在查看差异前获得方向感；视角应处于模块边界层面，只包括关键内容：新增／变更的类型、模块边缘的签名、依赖边缘变化和契约变更，不要罗列清单。差异代码块应作为按文件、按需查看的证据，而非默认讲解内容。然后再讨论主题。

主题形式。 一次只呈现一个审查主题（探查、权衡、建议）。每个主题都应让审查者无需打开补充材料就能作出一个判断：用代码库中的术语指出具体问题，再给出建议。不要使用嵌套从句、夹带论证或叙述推理。把理由、代码摘录和替代方案放在补充材料中（后续消息或按需探查），不要放进标题。等待用户回应后再继续。不要把主题打包提问——“你对这些有什么看法？”正是此技能旨在避免的失败模式。如果已有证据仍然支持原判断，就要在受到质疑时坚持立场。

先分类，再发布。 记录用户对每个主题的回应。审查过程结束后，将所有记录项——包括对主题的回应和自由备注——分为三类：已达成一致的判断，整理为草稿评论；用户提出的问题，必须先行答复——查阅代码、仓库的 ADR 以及 PR 所实现的任何设计文档（获取该文档；设计与实现之间的偏差是重要的审查依据），因为调查往往会推翻或改变原本拟写的评论；以及不予采纳的事项，不产生任何内容。然后逐条与审查者确认拟提交的评论——批量审批表会重现此流程旨在避免的信息过载；能够对应具体代码位置的评论应锚定到具体行，否则锚定到文件或 PR 层级。所有事项确认后，使用可用的 GitHub 审查机制，将这些评论作为一次 PR 审查发布。审查发布后，本次流程结束。 --canvas。 加载 references/CANVAS_MODE.md。HTML 工件取代聊天，成为演示界面——它是一张图片，而非文档：一张持久显示 PR 的系统地图，配有分步讲解、固定的评审主题、随处评论功能，以及按需打开的差异抽屉；所有内容一次性生成并立即打开。用户可按自己的节奏浏览，然后将汇总后的评审内容交回聊天，由上文所述的分类处理接手。