| name | request-review |
| description | 向跨家族 peer-reviewer 发送 review 请求(含五件套)。 Use when: 自检通过后准备请其他猫 review。 Not for: 收到 review 结果(用 receive-review)、自检(用 quality-gate)。 Output: Review 请求信(存档到 review-notes/)。
|
| triggers | ["请 review","帮我看看","request review"] |
SOP 位置: 本 skill 是 sop-definitions/development.yaml stage review 的执行细节。
SOP definition: sop-definitions/development.yaml stage review。
上一步: quality-gate | 下一步: receive-review
Request Review
把改动送到 reviewer 眼前,让 reviewer 花时间在重点上——不是基础检查上。
核心知识
前置条件(三项都要满足才能发请求)
| 条件 | 检查方式 | 未满足时 |
|---|
quality-gate 通过 | 有本轮 gate report | BLOCKED — 先跑 quality-gate |
| 测试全绿 | 附测试命令输出 | BLOCKED — 修到绿灯再发 |
| 原始需求可引用 | Discussion/Interview 文档路径 + ≤5 行摘录 | BLOCKED — reviewer 有权拒绝审查 |
| Architecture ownership 已声明 | 附 Architecture cell / Map delta / Why | BLOCKED — 回 Design Gate / plan 补齐 |
| 前端改动已浏览器实测 | Playwright/Chrome 截图证据 | BLOCKED — 涉及前端必须真实打开浏览器验证 |
| 根目录工件闸门通过 | 无根目录媒体/设计工件(工作树 + 已提交差异) | BLOCKED — 先归档/清理再发 |
教训(F041):review 信只附了 spec,没附原始 Discussion。结果 multiple remote review rounds 全在抓 edge case,没有一轮说"UI 不可用"。Reviewer 没有上下文,无法做愿景验证。
Reviewer 匹配规则
从 cat-config.json 动态匹配,三猫都不能 review 自己的代码:
优先级(从高到低):
1. 跨 family(author family ↔ reviewer family)
2. peer-reviewer 角色标记
3. 当前可用(无正在进行的 review 任务)
工具落点自检(Codex apply_patch 陷阱)
在 worktree 分支上用 apply_patch 改代码时,改动可能落到主 worktree(cat-cafe/)而非当前 worktree。发请求前必须确认:
git status
流程
BEFORE 发 review 请求:
1. 确认 quality-gate 已通过(拿到本轮 gate report)
2. 确认测试全绿(附这次真实运行的输出)
3. 找到原始 Discussion 文档路径 + 摘录 ≤5 行operator experience
4. 抄入 Architecture ownership 三字段(F191):
- `Architecture cell: ...`
- `Map delta: none | update required | new cell required`
- `Why: ...`
5. 检查 worktree 工具落点(git status 干净)
5.5 检查根目录工件闸门(两条都要为空):
- `git status --short | rg '^.. [^/]+\.(png|jpe?g|webp|gif|webm|mp4|mov|wav|pdf|pen)$'`
- `git diff --name-only origin/main...HEAD | rg '^[^/]+\.(png|jpe?g|webp|gif|webm|mp4|mov|wav|pdf|pen)$'`
6. 匹配 reviewer(跨 family 优先)
7. 用模板写 review 请求 → 存档 mailbox
8. 发给 reviewer
Review 请求
使用 refs/review-request-template.md 模板(单一真相源,不在此重复)。
关键字段提醒:
- Original Requirements: 必填,≤5 行operator experience + 来源文档路径,并明确请 reviewer 对照判断
- Architecture Ownership: 必填,列
Architecture cell / Map delta / Why,并请 reviewer 检查 diff 是否与 Map delta 一致
- Open Questions: 分为两类——技术 OQ(给 reviewer 的,如实现正确性)和 价值 OQ(需要 operator 判断的,附 Decision Packet——格式见
refs/decision-matrix.md)。不混在一起
- 自检证据: 附 quality-gate report 摘要 + 测试命令输出 + 根目录工件闸门输出
F191 reviewer 视角:
- PR 是否新建了并行
Store / Queue / Router / Adapter / Dispatcher / Binding?
Map delta: none 是否与 diff 一致?
- 若修改了
docs/architecture/ownership/cells/*.md,是否真是 owner/boundary/extension point/canonical anchor 变化?
Reviewer 怎么把 verdict 落到 PR 上(GPT 系 offline / 跨家族不可用降级到Ragdoll互 review 时尤其要看):
- ❌ 不要
gh pr review --approve —— 所有猫猫共享一个 GitHub 账号 zts212653,author 和 reviewer 是同一 GH login,GraphQL 会直接报 Review Can not approve your own pull request。白费 token,已多次踩雷
- ✅ 正路
gh pr comment {N} --repo … --body-file <verdict.md> —— logical-approve 落 issue comment(生成 #issuecomment-* 锚点,PR 时间线可追溯),评论正文写明:verdict(APPROVE/REQUEST-CHANGES/COMMENT)、覆盖的 HEAD SHA、独立验证证据(不要只信 author 转述)、签名
- 这条不是降级方案,是同 GH 账号下的标准路径。完整说明 + 教训锚点(cat-cafe#941)见
refs/opensource-ops-inbound-pr.md §self-approve / COMMENTED review 段——inbound PR 和内部 PR 一视同仁
- 案例:cat-cafe#2357 / #2359(2026-06-17,GPT 系 offline 降级到 47 review 46 author)— 47 撞了两次
--approve 失败才记起这条规则,已沉淀到 feedback_intake_review_on_github
存档:review-notes/YYYY-MM-DD-{topic}-review-request.md
Review 沙盒约定(review-target-id)
Review 请求必须包含 review-target-id,reviewer 据此创建标准路径的沙盒,merge-gate 回收时依赖此 ID。
review-target-id 推导规则:
- 分支名含
fNNN → 取 feature ID(如 f113)
- 无 Feature ID → 取 branch slug(如
fix-redis-keyprefix)
在 review 请求信中附上:
Review-Target-ID: {id}
Branch: {branch-name}
Reviewer 创建沙盒的标准路径:
/tmp/cat-cafe-review/{review-target-id}/{reviewer-handle}
例:/tmp/cat-cafe-review/f113/codex
Reviewer 启动命令(统一入口):
pnpm review:start
说明:
- 该入口默认在 review 沙盒内运行,自动分配隔离端口(起点 3201/3202)
- review 请求信里必须记录实际启动端口(web/api)
沙盒必须是 detached HEAD / read-only。要改代码 = TAKEOVER,开正式 worktree。
Block 场景
❌ 没有 quality-gate 报告
⚠️ BLOCKED — 缺少 quality-gate 自检报告
请先运行 quality-gate skill,确认:
- 原始需求逐项对照
- 测试/lint/build 全绿
- 有本轮输出证据
再发 review 请求。
❌ 没有原始需求摘录
⚠️ BLOCKED — 缺少原始需求文档
请附上:
- operator Discussion/Interview 文档路径
- ≤5 行operator experience摘录
Reviewer 不只审代码质量,还要判断"这是operator要的吗?"
没有原始需求 = Reviewer 无法做愿景验证 = 有权拒绝审查。
❌ 测试未通过
⚠️ BLOCKED — 测试未全绿
请先修复,再发请求:
pnpm test # 必须 0 failures
pnpm --filter @cat-cafe/api test:redis # Redis 改动额外跑
Reviewer 不应该是第一个发现测试失败的人。
Reviewer 视角:Failure-Mode Sweep Report(§16e)
R2+ 且同型 finding 再次出现时,reviewer 应期待 author 在 PR comment 提交 Failure-Mode Sweep Report(pattern name / scanned N / fixed / N/A 列表)。没有 Sweep Report = author 没做 failure-mode audit → reviewer 有权要求补做后再继续 review,不浪费 round 逐点抓同型。
和其他 skill 的区别
| Skill | 关注点 | 时机 |
|---|
quality-gate | 自检(spec 对照 + 证据) | review 之前 |
| request-review(本 skill) | 把改动送到 reviewer 面前 | 自检通过之后 |
receive-review | 处理 reviewer 的反馈 | 收到 review 之后 |
merge-gate | 合入前的门禁 + PR + remote review | reviewer 放行之后 |
下一步
Review 请求发出后 → 等 reviewer 回复 → 直接加载 receive-review skill 处理反馈(SOP stage review)。SOP 链条自动推进,不要停下来问operator(§17)。