先确认输入，再对照完整交付物
下面保留了原始材料、逐项结果和完整报告。先独立处理输入，再用参考结果检查遗漏与分歧。
下方 PR、提交标识与参考结果为合成快照。2026-10-18 另只读核对了本站公开 PR #3 及对应 head 的检查和评审；Notion 写入、通知、持续跟进与 Routine 未测，见页末记录。
本站原创合成材料。先看输入独立练习，再切换参考结果对照。
原始合成材料
{
"synthetic": true,
"case": "github-pr-watch",
"data": {
"prs": [
{
"id": "PR12",
"head": "new-b",
"checks": [
{
"sha": "old-a",
"status": "success"
},
{
"sha": "new-b",
"status": "pending"
}
],
"review": "unknown",
"state": "open"
},
{
"id": "PR13",
"head": "c",
"checks": [
{
"sha": "c",
"status": "success"
}
],
"review": "changes_requested",
"state": "open"
},
{
"id": "PR14",
"state": "merged",
"merged": true
},
{
"id": "PR15",
"head": "d",
"draft": true,
"checks": [
{
"sha": "d",
"status": "success"
}
],
"review": "not_reviewed",
"state": "open"
},
{
"id": "PR16",
"readable": false,
"error": "无读取权限"
}
]
}
}本次处理规则
只判断快照，不推断所有分支保护。成功检查必须关联当前提交，旧 SHA 成功不替代新 SHA。CI通过、评审、草稿、冲突和合并状态分列；无权读取为未知，不当成已关闭。
按本篇规则编写的完整参考结果，未写入第三方服务。表格较宽，可左右滑动查看。
| PR | 当前事实 | 状态建议 | 下一步 |
|---|---|---|---|
| PR12 | 新提交 pending；旧提交成功 | 等待检查 | 跟进 new-b，不能报全部通过 |
| PR13 | 检查通过；changes_requested | 待处理评审 | 查看未解决意见 |
| PR14 | 已合并 | 退出进行中 | 保留合并记录 |
| PR15 | draft；检查通过 | 仍为草稿 | 待作者转为可评审 |
| PR16 | 无权限 | 未知 | 报告读取阻塞 |
旧提交的绿色状态不能证明新提交已通过。
CI 成功与 changes_requested 同时成立，不能据此直接标为可合并。
PR 跟进摘要｜合成快照 PR12：等待 new-b 检查；old-a 成功已过期。 PR13：处理评审意见，不以 CI 成功覆盖 changes_requested。 PR14：已合并，退出进行中。 PR15：仍为 draft，未到待评审。 PR16：无权限，状态未知。 未确认：真实分支保护、冲突与安全扫描完整性。 没有更新看板、通知他人、合并或推送。
把材料与工具准备清楚
先用材料练习
- 下载五条 PR 快照，按当前提交判断检查。
- 练习编号不是真实 GitHub PR。
- 先不提供参考待办表。
接入真实环境时
- 明确仓库与 PR 清单，不全站搜索。
- 核对检查和评审读取能力，以及是否能确定最新提交。
- 写看板、联系负责人或重跑 CI 都另定范围，先只读。
先用下面的材料和指令完成一次文件练习。接入自己的服务时，核对实际账号、可用工具与操作范围，再按每步的检查点继续。
先下载原始材料与规则 ↓执行与接管边界
以下动作以已约定的输入、账号和范围为前提；设置 Routine 不会扩大授权范围。
可自动执行
只读指定 PR 的当前提交、检查与评审，分别报告冲突、草稿和合并状态。
需要确认
写 Notion 状态、通知负责人、提交评审、改代码、重跑 CI 或合并前确认具体动作与目标。
失败后接管
检查与当前 SHA 不匹配或无权读取时标未知；由你打开对应提交核对，恢复后只更新确有变化的记录。
先固定 PR 身份与观察时间
PR编号必须连同仓库识别，不能跨仓库混在一起。真实运行还要记录观察时间和当前提交，否则旧报告难以解释。
清点上传五条记录与可读状态，列当前 head 与缺失项。仅处理快照，不连接 GitHub/Notion，不通知负责人，输出 index.md。五条身份与缺项索引。
PR16 保留未知，PR14 的已合并状态没有丢失。
只把最新提交的检查计入结果
检查可能针对旧 head 或测试合并提交，应按平台规则核对当前有效检查。练习只使用显式 SHA 对照，不自行补分支保护。
对照 head 与 checks.sha，单列旧提交检查和当前检查。PR12 的 new-b 仍 pending，old-a success 不参与“当前通过”。列未确认保护规则。与提交关联的检查表。
PR12 没有被写成检查全部通过。
分别判断评审、草稿与合并状态
CI、review和draft是不同维度，不能一个绿色按钮概括所有条件。未能读取的评审也应保留未知。
逐 PR 列 CI、review、draft、merged 与可读状态，按规则给下一步。PR13 保留 changes_requested；PR15 保留 draft；不推断“可合并”。五行状态与建议。
PR13 和 PR15 没有因为 CI 成功升级为可合并。
写待办报告，修改看板先留差异
报告按问题组织，但不能自动把状态建议当作已写入看板。保留依据与原值，用户才能审阅状态迁移。
输出报告和看板变更建议：原值未知则写待核对；每行附 PR id 与原因。已合并退出进行中，无权读取保留未知。只写文件，不发消息、不改看板。摘要与待写变更清单。
建议和实际写入清楚区分，五条都可回查。
真实只读复查后再确认具体写入
从快照到操作之间，PR可能已有新提交。写状态前重新读取，检查是否仍是同一个head和评审状态。
只读 <仓库/PR清单>，记录最新 head、检查、评审、草稿、合并与读取时间。若获批准更新指定 Notion 行，先展示前后差异并回读结果。不通知其他 Agent、不重跑CI、不合并或推送。真实状态报告或明确的权限阻塞。
写入依据仍是最新版本，没有把旧摘要当当前事实。
只在有新变化时跟进
持续检查不应重复制造同一通知，但持续不可读也不能被当作没有变化。按状态版本记录，保留恢复与新问题。
保存 pr-watch Skill：仓库与PR、head+观察状态、上限、差异、失败与恢复处理。Routine先给草案；无变化安静。联系负责人需独立授权，不能自动跨Bot委派，不执行代码动作。复跑规则与通知边界。
同一状态不重复通知，新的提交会重新检查。
卡住时先看证据，再决定下一步
昨天绿色今天仍报告通过
核对最新提交与检查身份，旧成功不能沿用。
评审请求改动却标可合并
把CI与人工评审分列，保留未处理意见。
403 当成 PR 已关闭
权限错误属于未知，不能推断业务状态。
想自动叫编码代理修
先写问题和依据，在具体授权前不委派或发消息。
完成前，逐项核对
勾选用于本次自查，刷新后重置；不代表真实服务已经通过验证。
已核对 0 / 6 项
原始输入与参考答案分开下载
第一次先交原始材料和规则，不提前提供参考答案。验收后，再下载报告与全部提示词保存。
把官方能力与练习结果分别核对
内容更新日期： · 修改页面不等于重新核验资料或实操。
资料核验：已按记录范围核验 ·
已核对最新提交/测试合并提交的有效检查、评审与合并状态；公开读取与 Notion 写入、持续跟进分开验收。
实操核验：部分核验（含未通过项） ·
部分核验：Grok Bot 只读了本站真实公开 PR #3、当前 head 对应检查与评审，原始接口结果已复核；CI、评审和已合并状态分别记录。未测未合并 PR 的持续跟进、分页、Notion 写入、通知或 Routine；mergeable=null 保持未知。
最近实操尝试： · 尝试日期不代表已核验通过。
下方 PR、提交标识与参考结果为合成快照。2026-10-18 另只读核对了本站公开 PR #3 及对应 head 的检查和评审；Notion 写入、通知、持续跟进与 Routine 未测，见页末记录。
- GitHub：必需状态检查排错 ↗
核对最新提交与有效检查；本页只演练合成状态。
- GitHub：评审处理 ↗
评审意见与检查结果分别判断。
- Grok Bot：应用与共享电脑 ↗
核对连接方式、可见范围与账号内共享状态。
- Grok Bot：Skills 与 Routines ↗
先验证一次手动任务，再保存与安排重复运行。