pr

pr — 一份能被机器检、能被人按图索骥的 PR

产物是一个 GitHub PR：body 按 assets/pr_template.md 的段落序呈现（产物序，出口可检）。本文件 写：PR 在流水线里是什么、什么算写对、原语与出口、建之前的门。先 rebase 还是先写 body、要不要拆 是你的份额——除非下面说了它是不可逆的。

缺口（Judgment + Capability + Control）

deletion 测试：撤掉本 skill，引擎 git push && gh pr create --fill：标题是最后一条 commit，body 是 commit 列表。reviewer 不知道范围在哪、AC 有没有被覆盖、怎么验证；/review-loop 判"越界"没有 基准；1200 行的 diff 一次扔过去。缺的是 body 的产物序判据、体量判据、以及把这些编译掉的预门。

世界（Σ）

• PR body 的范围声明是下游的基准：/review-loop 判"越界类"评论对照它；/pr-review 判 B 档 "公共 API 变更"对照它。写得越具体，后面判定越省力。
• AC → 证据映射是 A 档验收的输入：每条 mechanical AC 对应一个可复现的证据（测试名 + 命令 + 结果、或 evaluation_result 路径）；human AC 标 judge: <角色> 等 G3。
• 证据会随分支增长而失效：git diff --stat <首个卡提交>^..HEAD -- <目录> 这类开放端点的 原始命令，写下时为真，此后任何非卡的提交落在首个卡提交之后就让它变假——同一条命令，同样的 断言，第二天再跑结果不同（dogfood 2026-09-06，I-79：两条修复提交把"空"变成 5 files / 11 insertions）。 "某类提交没碰某些目录"的承重证据是卡范围的回放仪器（按卡的 commit 列表逐个 replay，如 dogfood/ring-audit/replay_card_commits.sh 的 card_commits_touching_audited_dirs），它只看卡的提交， 分支后续怎么长都不改变结论。原始 diff 只能当补充，且必须钉死两端 + 标记录时刻。
• 体量（按 diff 行数）：XS < 50 · S < 200 · M < 500 · L < 1000 · XL ≥ 1000。L 建议拆， XL 必拆（按卡 / 按目录 / 先重构后功能）——long-context 下 review 质量崩，这是经验事实不是偏好。
• push 不可逆、PR 公开：push 之前该确认的都在预检里；PR 建了之后改 body 可以，但已通知的 reviewer 已经读过第一版。
• Draft 的语义：还想再改 / B 档有告警 / 等 CI 结果 → draft；--draft 或预门 flags 非空时默认 draft。
• base 分支：git config branch.<b>.merge → gh repo view --json defaultBranchRef → 问用户。
• 关于用户的 Σ："提上去" = push + 建 PR；"先别通知人" = draft；"顺手合了" ≠ 本 skill 合—— merge 是人类动作。

判据（φ）

• 预检（拒）：当前分支 ≠ base；git status 干净；与 origin/<base> 无落后（有则 merge—— 不 rebase 已推送分支）；范围内每条非 merge commit 消息合规（Conventional Commits）；自检绿 （入口推断同 /commit）或 body 注明 untested。merge 提交的主题由 git 生成，而"落后就 merge"正是 本预检自己的要求——把它按 Conventional Commits 判拒等于照做就过不了（I-74）；按 parent 数放行， 非 merge 提交照判不误。
• 插件版本同步（拒）：范围 diff 触及 plugins/<p>/skills/** 而 plugins/<p>/.claude-plugin/plugin.json 的 version 未变（或 marketplace.json 与它不一致）→ 拒（--no-version-sync 显式豁免）。 PR 范围看得见整个交付，版本 bump 就该在里面；插件缓存按版本号取目录，不 bump 的修复等于没发。
• body 段落（拒）：Summary / Scope（do / dont）/ Linked issue（Closes #N 或 Refs #N）/ Changes / Verification（至少一条命令或测试证据）/ Acceptance mapping（有 --done-when 时每条 mechanical AC 都出现）/ Risk & rollback / Reviewer focus。
• Verification 里的证据形态：命令要么两端钉死（<sha>^..<记录时的 sha>，并注明记录时刻）， 要么用卡范围的回放仪器——以 ..HEAD 收尾的原始 diff 不能承载"某些提交没碰某些目录"这种 否定断言（见 Σ / I-79）。断言在 PR 正文里必须此刻仍为真，不是记录当时为真。
• 体量：XL → 拒（除 --allow-xl 并在 body 写明为什么不能拆）；L → flag。
• 锁（--lock 或 .done_when.lock 存在）：范围 diff 触及锁文件且无变更提案 → 拒。
• 标题：type(scope): subject 同 commit 规则（≤ 72）。
• 预审（--pre-review）：建 PR 前用新上下文的 agents/pr-reviewer.md（跨供应商优先；同源则标 single-vendor caveat）审 base..head 的 diff，最多 --rounds（默认 2）轮"修复 → 再审"——业界数据：自审 2–3 轮后收益见顶，且约减少 1/3 的 review 往返。 两轮后仍存活的发现写进 body 的 ## Known issues（每条带 file:line），不再迭代，留给人看；A 档 / P0 不许作为 known issue 出现——修掉它。verify_pr.py --pre-review 检该段存在、每条有锚点、无 A 档。预审不替代 reviewer：它减少的是 nit，不是判断。
• 残差：Summary 是否诚实；Reviewer focus 是否指向真正的风险点。