pr-triage

PR 分流

按提交时间或大小排序的审查队列，会让人先看错 PR。900 行的重命名无伤大雅；价格只改一个标记，却不然。此技能会读取每个未合并的 PR，判断每项更改的实际影响程度，并重新排列队列，让真正需要关注的 PR 排在前面。无需配置任何内容。

它会引导关注，但绝不批准。队列中的最后一个 PR 仍会被审阅。每项判断都会指出影响该判断的行，每个 PR 也都会链接到根据相同数据生成的阅读导览，让审阅者只需点击一次即可核实判断。

脚本位于与此文件同级的 scripts/ 中（Node ≥ 18，无依赖，gh 已登录）。如果你通过 HTTP 获取了此文件，请使用 curl -sSL 获取 scripts/*.mjs 和 references/ 中的文件原始文本。

流程

1. 检查登录状态。 node scripts/preflight.mjs 会为每个仓库打印一行；对于状态不是 ready 的行，会显示安装链接或登录命令。绝不要索要令牌或执行登录；将命令交给用户。状态为 ready 即完成；否则，连同表格报告 BLOCKED。
2. 计算。 node scripts/triage.mjs（在仓库外添加 --repo owner/name）。对于每个开放的 PR，它都会写入 .pr-review/tour-<n>.json，其中包含文件、噪声、FACT 项、阅读顺序和作者原话；还会写入列出这些 PR 的 .pr-review/triage.json，将每个 PR 的 head 拉取一次到 origin/<head> 供评审者使用，并生成尚未评审的页面。此过程不会涉及模型。仓库列表会生成一个队列（参见 多个仓库）。重新运行会替换报告和页面（包括评审结果），并移除已关闭 PR 的报告和页面——最后一次运行后再评审。 开放 PR 超过 20 个时：说明数量，并在全部评审前征求同意。
3. 逐个独立评审 PR。 对每个 tour-<n>.json，阅读对应 PR 的内容——gh pr diff <n>、快速浏览噪声部分，以及 PR head 中的周边代码（先执行 git fetch origin <head>，再执行 git show "origin/<head>:<path>"——绝不要使用 FETCH_HEAD，并行评审者会覆盖它）——然后按照 references/notes.md 的格式写入 .pr-review/tour-<n>.notes.json，并包含 attention 块。接着执行 node scripts/annotate.mjs .pr-review/tour-<n>.json .pr-review/tour-<n>.notes.json——该命令会将通过检查的评审备注写入 tour-<n>.json——并不断修正备注，直到通过检查。 尽可能为每个 PR 使用一个全新的子 Agent，并行处理，且每个子 Agent 只能收到下方的评审说明。读过其他 PR 的评审者会受到对比基准影响。如果不使用子 Agent，则逐个评审，并独立依据各 PR 的实际情况作出判断。
4. 排列队列。 阅读每个 PR 的 attention。写入 .pr-review/triage.notes.json：{ "summary": "...", "order": [7, 6, ...] } ——使用 triage.json 中每个 PR 的 key（多个仓库时为 "dmoka-ticket-bay-7"），按关注级别从高到低排列，涵盖所有仓库。同一等级内，按以下顺序依次比较，遇到能区分两个 PR 的首项即停止：不可逆的优先于可逆的；正在运行的代码优先于尚未被调用的代码；与其他 PR 冲突的 PR（overlaps）优先于无冲突的 PR；较早的优先于较新的。总结用两三句话概述整个队列；使用 triage.json 中的 overlaps（两个或更多 PR 修改的文件）判断 PR 之间的冲突。 node scripts/annotate.mjs .pr-review/triage.json .pr-review/triage.notes.json 会检查每个 PR 是否恰好列出一次、已评审，且绝不会排在较低等级的 PR 之后。
5. 生成页面。 node scripts/render.mjs .pr-review/triage.json 会写入 .pr-review/review.html：一个文件包含队列和所有评审页面，每个页面都有独立侧边栏，并可即时切换（#/pr/7）。无需服务，可安全地作为 CI 构建产物发布。报告前先查看队列——如果有浏览器，就在浏览器中查看（若 file:// 被阻止，使用 python3 -m http.server -d .pr-review；没有浏览器时，使用无头 Chrome 的 --dump-dom 打开文件并进行相同检查）。检查：没有 PR 显示“not judged”；顺序与评审备注一致；每个证据链接都能打开对应评审页面的正确行。
6. 报告 在聊天中给出：review.html 的路径，然后列出队列——等级、PR、发生了什么、原因——完整列出 critical 和 high，其余每个各用一行。

评审指南

填写绝对路径和 HEAD_BRANCH（tour-N.json 中的 pr.head），并将以下内容原样交给每位评审：

评审 git 仓库 REPO 中的拉取请求 #N（在该目录中运行命令）。阅读 SKILL_DIR/references/notes.md 并遵照执行。使用 gh pr diff N 和 gh pr view N 阅读 PR；使用 git show "origin/HEAD_BRANCH:<path>" 阅读 PR 头提交中的周边代码——它已获取；不要运行 git fetch。绝不要切换分支——其他人共用此工作区。略过无关内容；如果 作者声称某些内容“仅格式调整”，请使用任意工具核实该说法。写入 REPO/.pr-review/tour-N.notes.json，其中包含 attention 块，然后运行 node SKILL_DIR/scripts/annotate.mjs REPO/.pr-review/tour-N.json REPO/.pr-review/tour-N.notes.json；它会将 你核查过的 notes 复制到 tour-N.json。修正 notes，直到通过检查。不要操作 GitHub 或任何其他文件。回复你的 attention 块。

多个仓库时：N 是 PR 键。评审使用 tour 的 read.diff、read.show 和 read.grep（而不是 gh、也不是 origin/...）阅读，并参考其 intent。

多个仓库

• 配置： ~/.config/pr-triage/repos.jsonc（Windows： %USERPROFILE%\.config\pr-triage\repos.jsonc），带注释的 JSON： { "repos": ["github:<owner>/<repo>", ...] }。没有该文件时使用当前仓库； --repo 会忽略此配置。gitlab:/azure: 条目会被跳过，并提示“not supported yet”。
• 登录检查（步骤 1），逐个仓库进行：已安装 git 和 gh，已登录，且可以 读取该仓库。只对 ready 仓库进行分流；页面会先列出其余仓库。
• 缓存： ~/.cache/pr-triage/github/<owner>/<repo>，部分克隆 （--filter=blob:none），没有工作树。每次运行都会将所有打开的 PR 头提交获取到 refs/pr-triage/pr/<n>，更新默认分支，并删除已关闭 PR 的 refs。它绝不会触碰你的工作区；损坏的缓存会重新克隆。删除缓存：node scripts/triage.mjs --clean-cache [github:<owner>/<repo>]。
• 键： PR 在文件名、链接和队列顺序中使用 <owner>-<repo>-<n>（dmoka-ticket-bay-33）； 每张卡片都会显示其仓库。

硬性规则

• 评审改动，而不是改动规模、标题或作者。 先阅读 diff 再评审。标题可能掩盖改动；这正是需要多加留意的理由。
• 不要下结论。 注意级别是阅读顺序的指引。绝不要称 PR“安全”、“LGTM”、“没问题”、“可以合并”或“无需评审”。检查关卡会拒绝常见措辞；此规则也适用于其他类似表述。
• 所有高于低级的级别都必须指向具体行，并附上检查关卡会核验的原样代码片段。没有行号，就不能作出判断。
• 在 GitHub 上只读。 绝不要评论、添加标签、批准、请求更改、分配任务或合并。输出保存在 .pr-review/ 中；如果 .gitignore 和 .git/info/exclude 都未涵盖该目录，请建议将其加入。

排名无法看出的内容

• 代码能否运行。 无人运行代码。评审者负责阅读；测试负责运行。
• 读者会遗漏的所有内容。 模型只能发现细心的人类能找到的问题中的一小部分。低级表示“读者没有发现明显问题”，绝不表示“已检查”。
• 仓库之外的背景： 截止日期、等待的人，以及本周业务关注的事项。如果这些因素会改变排序，请说明。
• 稳定性。 两次运行可能会将 PR 排在同一级别的不同位置。级别本身不应变化；若发生变化，请在线索行中说明原因。

完成标准

• triage.json 通过了 annotate.mjs，每个 tour 的 notes 也都通过了检查。
• review.html 已生成，且能从队列打开每个 PR 的 tour。
• 聊天报告列出队列、级别和理由，最需要关注的排在最前。
• GitHub 上没有任何改动。

注意事项

• 切勿在缓存中运行 git fetch：triage.mjs 已获取每个分支头， 并行获取会导致 refs 冲突。

每个导览中的意图映射、用于查找作者意图的搜索顺序 以及新会话规则，均改编自 Matt Pocock 的 code-review 技能（MIT）。

最后验证时间：2026-09-28，使用 Hermes v0.21.5（dmoka/ticket-bay 上的晨间 cron 作业）