用途
PR Tour 把一次 Pull Request 拆成一段引导式阅读之旅，解决评审者按 Git 输出的字母顺序通读 diff 的问题。它改变的是「先读什么」：先看作者意图（WHY），再看重要文件，噪音放最后。它只引导注意力，不做判断——不给合并结论，也不给安全结论；「collapsed（折叠）」表示阅读价值低，绝不表示「已检查」。
主要能力
- 计算导览数据：运行
node scripts/tour.mjs <pr-number>，生成.pr-review/tour-<n>.json，包含 FACT 条目、逐文件分类、阅读顺序，以及从各来源发现作者原话（强度由高到低）：规格文档（docs/、specs/、.scratch/、contracts/下文件名含分支名的 markdown）、PR 描述、关联 issue 与 commit 中的#123引用、commit 信息、标题。意图状态分为 spec、described、title only、UNKNOWN。 - 噪音折叠：锁文件、重命名、格式化、生成文件（ORM 快照、压缩包、大型机器生成 JSON、带生成头的文件等）会被放到最后，并打印噪音行数；噪音文件永远不会被列为 ASK WHY。
- 写出 WHY 笔记：
.pr-review/tour-<n>.notes.json，可含 attention（critical/high/medium/low）、whatItDoes、why、points、shape、diagrams、chapters、explains（意图映射）、claims（可核对的承诺）、items（最多 8 个 LOOK HERE 指针）、fileNotes。 - 校验门禁：
node scripts/annotate.mjs <tour.json> <notes.json>会拒绝非逐字引文、行号不含所指代码的指针、意图映射中的噪音文件、超过 8 个条目以及判决式词汇，并推导出未被解释的文件、未匹配的引文，重新计算阅读顺序。 - 渲染：
node scripts/render.mjs <tour.json>在旁生成自包含 HTML（查看器与数据同在一个文件，无需服务器，可作为 CI 产物发布）。
使用方式
- 在全新会话中开始，不要用写该 diff 的会话运行。
- 运行
node scripts/tour.mjs <pr-number>；仓库外可加--repo owner/name，PR 尚不存在时用--git main...feat/x，规格或评审契约在别处时用--spec <path>，用--out <dir>改输出目录。 - 按阅读顺序读 diff（噪音也略读），在不 checkout 的情况下于 PR head 读周边源码：
git fetch origin <head>，再git show "origin/<head>:<path>"（加引号）。 - 按
references/notes.md的格式写 notes.json。 - 运行
annotate.mjs校验；修正笔记，不要改检查逻辑，可安全重跑。 - 运行
render.mjs生成 HTML，并在浏览器中查看或至少确认 JSON 中 WHY 面板文字正确。 - 在聊天中报告：HTML 路径、意图状态、未解释文件、high 级别条目（含 file:line）、噪音行数。
运行环境：Node ≥ 18，零依赖，需 gh 已登录；脚本位于本文件旁的 scripts/，若通过 HTTP 获取，需用 curl -sSL 以原始文本取回 scripts/*.mjs 与 references/config.md。
适用场景
- 人类评审者需要快速抓住 PR 意图与关键改动。
- 智能体评审时按 JSON 的 severity 从 high 开始处理。
- 将导览 HTML 作为 CI 产物发布供团队阅读。
限制
- 无法判断代码是否能工作（需实际运行）。
- 不是漏洞扫描器，只提示缺失的安全决策；应另用 Trivy、opengrep 等工具。
- 被折叠的噪音未必无害（如锁文件可能携带恶意包，"仅格式化"文件靠启发式判断）。
- 看不到 diff 之外覆盖该文件的测试。
硬性规则
只指方向、不做判决（不得出现 LGTM、looks safe、approve、exploitable、no issues、nothing to review 等）；不得编造意图，只有作者原话算意图；FACT 条目须来自脚本；整个流程只读，不评论、不批准、不修改 PR 与代码。意图搜索顺序与全新会话规则改编自 Matt Pocock 的 code-review 技能（MIT）。资料标注最后验证时间：2026-09-25，配合 Claude Code（随 dmoka/skills #1 发布）。