用途：协助审阅者走查一个 PR 或大型 diff，既可用于自己的改动，也可用于他人的改动。核心是分批推进：先按“子变更集（SC）”把文件按合理关系分组，每个 SC 内一次只呈现一个审查主题。
读者模型：假定审阅者在本仓库工作，但对本 PR 毫无上下文。代码库既有词汇是共识基础，PR 新引入的词汇（新类型、模式、模块、领域术语）必须先明确介绍，再供后续内容使用。
注意力契约：所有模式都遵循同一约定——先高层定位，一次只激活一个想法；深度内容（理由、代码、diff、长文本）仅在审阅者要求时给出。任何呈现选择都要避免“文字墙”，不要一次给出超过当前想法所需的信息。
开场定位：在变更概览前给 PR 入门说明，包括一段用工作流词汇写的问题陈述；仅在必要时附概念词汇表（工作流层面定义，而非类型签名）、组件草图或阅读提示。随后给分类概览，区分承重改动与脚手架/数据，按信号强弱排序；琐碎 diff 可跳过。
每个 SC 按需展开深度：始终可见的只有一句行为摘要（对用户而言什么变了）和一句验证探针（如何观察其生效）。边界视图、主题、diff 等其余内容仅供审阅者在需要的 SC 上展开。深度内部以边界为先：用不超过三段短文字描述模块边界层面的新增/变更类型、模块边缘签名、依赖边变化、契约变更，只讲承重部分。diff 片段是按文件、按需给出的证据，不是默认展示。
主题形态：审查主题（探针、权衡、建议）一次只呈现一个。每个主题两句陈述句：先用代码库词汇具体表述关注点，再给出建议结论；理由、代码摘录和替代方案放在后续消息或按需探针中，不放在标题里。等用户回应后再推进，不要批量提问。证据仍支持时，面对反驳可坚持立场。
归类与提交：走查完成后，把每个主题的回应和随手笔记归为三类——已定结论（转为草稿评论）、必须先由你回答的审阅者提问（从代码、仓库 ADR、PR 对应设计文档中查证，设计实现偏差常是重要审查素材）、不产生任何内容的丢弃项。然后逐条与审阅者确认拟提交评论，能对应具体代码位置的锚定到行，否则按文件级或 PR 级；全部锁定后，用可用的 GitHub 审查机制一次性提交为单个 PR 审查。作者是否及如何处理评论属于下游 manifest 工作流，不由本技能负责。
--canvas 模式：加载 references/CANVAS_MODE.md。HTML 产物取代聊天作为走查界面，它是一张图而非文档：一张持续存在的 PR 系统地图，配合分步故事、钉住的审查主题、随处评论、按需抽屉中的 diff，预先一次生成并立即打开；用户自行浏览，再把合并后的审查包交回聊天，由上述归类流程接手。输入可以是 PR 编号、PR URL、diff 范围，或留空（推断当前分支的 PR，回退到 origin/main..HEAD）。
限制：资料未提供具体安装命令、依赖版本、支持平台与收费信息。