القائمة
向跨家族 peer-reviewer 发送 review 请求（含五件套）。 Use when: 自检通过后准备请其他猫 review。 Not for: 收到 review 结果（用 receive-review）、自检（用 quality-gate）。 Output: Review 请求信（存档到 review-notes/）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
约定图发现方法论：进一个 repo 先识别 repo-specific conventions，再定义 domain/extractor 接 Convention Graph 引擎。Use when: 进入陌生 repo、要画约定图、要找“改 X 影响谁”的约定层关联、 F242/Convention Graph Layer 工作。Not for: 普通符号跳转/LSP、文档索引检索、记忆图谱、直接使用 codegraph/GitNexus。Output: domain 定义 + extractor 计划 + gap/freshness/provenance 报告。 GOTCHA: 沉淀的是“怎么画图”的方法，不是把 cat-cafe 的 extractor 硬搬到所有 repo。
跨 thread 协同：发现平行 session → 通知（3+2 件套）→ 争用协调 → 确认。 Use when: 平行 session 之间需要协同、收到跨线程消息、通知改动影响、共享文件争用。 Not for: 跨猫工作交接（用 cross-cat-handoff）、需要新建 thread 时（用 propose_thread / thread-orchestration）。 GOTCHA: 收到跨线程 ACTION 不等于接活；先做 thread/feat ownership gate，不属于当前 thread 就 cross-post 退回。 Boundary with F128: 发现跨 scope 问题 → 先 list_threads 查有没有已有 thread → 有 = 本 skill（cross_post）→ 没有 = propose_thread。 Output: cross-post 通知 + 争用协调完成。
Feature 立项、讨论、完成的全生命周期管理。 Use when: 开个新功能、new feature、F0xx、立项、feature 完成、验收通过、讨论新功能需求。 Not for: 代码实现、review、merge（那些有专门的 skill）。 Output: Feature 聚合文件 + BACKLOG 索引 + 真相源同步。
明星开源项目拆解：从宣传/PPT/README 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent/runtime、外部 skill/tool 框架，或问“它到底有什么真本事/我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue/PR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions/YYYY-MM-DD-{project}-deep-dive/ 下的代码证据报告 + 对比结论 + 候选 lesson/skill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。
开发完成后的自检门禁：愿景对照 + spec 合规 + 验证。 Use when: 开发完了准备提 review、声称完成了、准备交付。 Not for: 收到 review 反馈（用 receive-review）、merge（用 merge-gate）。 Output: Spec 合规报告（含愿景覆盖度）。
接球前真相核验三问：claim → resolver → verdict (sourceTier T0/T1/T2 + actionFamily)， 防止把传球者当无审视真相源（F167 Phase O 第一性原理）。 Use when: 即将调 hold_ball / register_pr_tracking / register_issue_tracking / merge / takeover / 改 owner / 任何 irreversible action / 基于 "operator signoff" 或 "你是 owner" 类 claim 行动之前。 Not for: 纯阅读 cross_post（无 actionFamily 后续）；本 thread 日常 @mention 无副作用； implementation continuation（自检通过的下一步）。 Output: claim grounding verdict (verified/mismatch/insufficient) + 接球决策 (proceed / block / push back to source thread)。
| 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.yamlstagereview的执行细节。 SOP definition:sop-definitions/development.yamlstagereview。 上一步:quality-gate| 下一步:receive-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 没有上下文，无法做愿景验证。
从 cat-config.json 动态匹配，三猫都不能 review 自己的代码：
优先级（从高到低）：
1. 跨 family（author family ↔ reviewer family）
2. peer-reviewer 角色标记
3. 当前可用（无正在进行的 review 任务）
在 worktree 分支上用 apply_patch 改代码时，改动可能落到主 worktree（cat-cafe/）而非当前 worktree。发请求前必须确认：
git status # 只在目标 worktree 有变更，主 worktree 干净
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
使用 refs/review-request-template.md 模板（单一真相源，不在此重复）。
关键字段提醒：
Architecture cell / Map delta / Why，并请 reviewer 检查 diff 是否与 Map delta 一致refs/decision-matrix.md）。不混在一起F191 reviewer 视角：
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 转述）、签名refs/opensource-ops-inbound-pr.md §self-approve / COMMENTED review 段——inbound PR 和内部 PR 一视同仁--approve 失败才记起这条规则，已沉淀到 feedback_intake_review_on_github存档：review-notes/YYYY-MM-DD-{topic}-review-request.md
Review 请求必须包含 review-target-id，reviewer 据此创建标准路径的沙盒，merge-gate 回收时依赖此 ID。
review-target-id 推导规则：
fNNN → 取 feature ID（如 f113）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
说明：
沙盒必须是 detached HEAD / read-only。要改代码 = TAKEOVER，开正式 worktree。
❌ 没有 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 不应该是第一个发现测试失败的人。
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 | 关注点 | 时机 |
|---|---|---|
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）。