change-review

Change Review & Archive

Overview

接管 dispatch runner 执行完成后的全部收尾流程：PR 审查 → 分形同步（在 feature branch 上）→ 本地 CI → rebase → 三维 Verify → 合并实现 PR → main-side sync → governance archive PR → 更新 backlog。

Branch-Centric 模型： 四件套和实现代码都在 feature branch 上，通过 PR 审查和合并。审查者可在 PR diff 中同时看到方案（四件套）和实现（代码），确保一致性。

可恢复闭环： 所有可能阻止交付的硬检查都在实现 PR 合并前完成。required checks 尚未完成时启用 auto-merge 并结束本轮；实现 PR 合并后，归档与共享治理文件通过确定性 governance/change-review/<change-id> PR 发布。重跑本 skill 会同时检查实现 PR 与 governance PR，因而不会重复 sync、move 或提交。

Announce at start: "Running change-review: checking for changes ready for review."

Bash 命令规范

为兼容 Claude Code / Codex 等不同执行环境的权限与审批模型，所有 Bash 操作必须遵循：

1. 每条命令独立调用 — 不在一条 Bash 中用 &&、||、; 串联多条命令
2. 管道可以用 — 单条命令内的管道（如 git branch -r | grep feat/）是允许的
3. 并行无依赖时分开调用 — 多条独立命令应作为多个并行 Bash tool call 发送

类型 → 分支前缀映射规则

type 的事实源是 product/backlog.md 的类型列（Step 1 方式 A 扫描 backlog 时同一行直接读到）；方式 B/D 从 PR 的 headRefName 分支前缀直接得到。由 type 映射 branch / commit 前缀：

type	branch 前缀	commit type
feature	feat/	feat
bug	fix/	fix
chore	chore/	chore
hotfix	hotfix/	fix

下方 Step 1 / Step 3 / Step 6 所有命令中的 <branch-prefix> 和 <commit-type> 均按本规则映射，不从 change-id 字符串反解析。

示例：

# ❌ 错误：复合命令触发确认
git fetch origin && git branch -r | grep feat/ && gh pr list --state open

# ✅ 正确：拆分为独立调用
# Call 1: git fetch origin
# Call 2: git branch -r | grep feat/
# Call 3: gh pr list --state open --json number,headRefName,title,isDraft

---

Step 1 — 发现待审查 Change

四种发现方式：

方式 A：扫描 Backlog + Feature Branch

读取 main 上 product/backlog.md，找到阶段为 proposed 且有 change-id 的条目（backlog 只有 4 阶段：idea/exploring/proposed/done；执行中 / 审查中的细粒度由 tasks.md YAML status 承担）。对每个 change-id：

git fetch origin <branch-prefix>/<change-id>
git show origin/<branch-prefix>/<change-id>:openspec/changes/<change-id>/tasks.md

筛选 YAML 头 status: review 的 change。

若 fetch feature branch 失败，但 main 上 backlog 仍为 proposed，不要直接放弃；进入方式 D 检查是否属于"已 merge 但未 archive"恢复场景。