菜单
处理 reviewer 反馈：Red→Green 修复 + 技术论证（禁止表演性同意）。 Use when: 收到 review 结果、reviewer 提了 P1/P2、需要处理反馈。 Not for: 发 review 请求（用 request-review）、自检（用 quality-gate）。 Output: 逐项修复确认 + reviewer 放行。
用 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 | receive-review |
| description | 处理 reviewer 反馈：Red→Green 修复 + 技术论证（禁止表演性同意）。 Use when: 收到 review 结果、reviewer 提了 P1/P2、需要处理反馈。 Not for: 发 review 请求（用 request-review）、自检（用 quality-gate）。 Output: 逐项修复确认 + reviewer 放行。 |
| triggers | ["review 结果","review 意见","reviewer 说","fix these","github-review-feedback"] |
SOP 位置: 本 skill 是
sop-definitions/development.yamlstagereview的反馈处理执行细节。 上一步:request-review| 下一步:merge-gate
处理 reviewer 反馈的完整流程。核心原则：技术正确性 > 社交舒适，验证后再实现，禁止表演性同意。
| 来源 | 说明 |
|---|---|
| operator/猫猫转述 | 手动告知 review 结果 |
github-review-feedback connector 通知 | F140 自动投递：review decisions（approved/changes_requested）+ inline/conversation comments |
| 云端 Codex review | 通过 ReviewRouter 投递的 email review 结果 |
收到 github-review-feedback 通知时，按下面的核心知识处理——不区分来源，只区分反馈类型。
当 github-review-feedback connector 唤醒你时：
CHANGES_REQUESTED → 直接进入下方 Red→Green 流程APPROVED → 不需要 receive-review，检查是否可以走 merge-gateCOMMENTED → 判断是否需要代码修改，需要则进入 Red→Green 流程详见 refs/pr-signals.md Phase B 自动响应行为。
| 类型 | 特征 | 处理 |
|---|---|---|
| 代码级 | bug / edge case / 性能 / 命名 | Red→Green 修复流程 |
| 愿景级 | "这不是operator要的" / "缺了多项目管理" / "UI 不可用" | STOP → 回读原始需求 → 升级operator |
愿景级反馈不能用代码 patch 修补设计问题。 先对照operator experience验证 reviewer 说得对吗；如确实偏离，升级operator确认偏差范围，再重新设计。
❌ "You're absolutely right!" ❌ "Great point!"
❌ "Excellent feedback!" ❌ "Thanks for catching that!"
❌ "让我现在就改"（验证之前）
行动说明一切——直接修复，代码本身证明你听到了反馈。
当以下情况时必须 push back，用技术论证，不是防御性反应：
如果你 push back 了但你错了：陈述事实然后继续，不要长篇道歉。
Review 代码时，自动执行 node scripts/check-fallback-layers.mjs 检测 fallback 模式增长。
同一文件新增 ≥3 层 fallback → 触发坐标系自检（三问）：
review 报告中必须包含 fallback 层数分析结果。
Review 有零分歧 = 走过场（反顺从规则）。真正的 review 需要技术争论。
WHEN 收到 review 反馈:
1. READ — 完整读完，不要边读边反应。**R2+ 时额外动作**：回看上轮 finding 列表，标注每个 finding 的 failure-mode 类型，用于 AUDIT 步骤的同型判别
2. CLASSIFY — 区分愿景级 vs 代码级；按 P1/P2/P3 分优先级
3. CLARIFY — 有不清晰的问题先全部问清，再动手
4. VERIFY — reviewer 说的问题真的存在吗？（见下方三道门）
5. AUDIT — failure-mode sweep（见下方 §16e 判别）
6. FIX — 通过验证的问题 + audit 发现的同类问题 Red→Green 修复
7. CONFIRM — 修完回给 reviewer 确认，不能自判"改对了"
对每条 review 意见，改代码之前必须过三道门：
特别注意：remote reviewer（Codex cloud）没有运行环境，判断基于静态分析和理论推理。你有本地环境 → 你的实测证据 > 他的理论推理。
修复顺序：P1（blocking）→ P2（必须修）→ P3（讨论后当场修或放下，不记 BACKLOG）
澄清原则：有任何问题不清晰，先 STOP，全部问清再动手。部分理解 = 错误实现。
VERIFY 完所有 findings 之后、动手修之前，做一次 failure-mode 判别：
判别问：这些通过验证的 P1/P2 里，有没有 ≥2 个属于同一类 failure mode？（边界遗漏、null 不安全、错误处理不一致、状态转换缺路径、类型假设不安全……）
R2+ 额外检查：如果本轮的 finding 和上轮是同型——不管数量多少，强制 audit。同型第二次出现 = author 上轮没泛化，这次必须补上。
≥3 轮升级规则（F229 PR-A1 20 轮教训）🔴：同一状态对象的 finding 连续 ≥3 轮出现（哪怕每轮都"修好了"）= 不是你修得不对，是 plan/spec 层欠状态机的边——代码层 audit 扫不出"spec 没定义 restore boundary"这种上游缺失。停手，@ plan/spec 作者按 writing-plans「Stateful Object Gate」补状态转移表 + 不变量，补完再继续修。别一个人打到 R20（PR #2202：实现猫每轮诚实修好当轮 finding，但缺这个升级出口，20 轮才合入）。
为什么在 FIX 之前：先 audit 再修 = 一次修完所有同类；先修再 audit = 改了一个又发现三个，反复 rebase。
对每个 P1/P2 问题：
Step 0: 创建修复任务（F160 Phase C — 在动手修之前）
调用 cat_cafe_create_task 为每个 P1/P2 创建独立跟踪任务：
[P{N}] {问题摘要}（如 [P2] TaskComposer HTTP 错误时丢失输入）cat_cafe_update_task 状态改为 doneGotcha: 不要为 P3 创建任务——P3 当场修或放下，不记 BACKLOG 也不记毛线球。
1. 理解问题
2. 写失败测试（Red）
3. 运行测试，确认红灯
4. 修复代码
5. 运行测试，确认绿灯（Green）
6. 运行完整测试套件，确认无 regression
例外：如果无法稳定自动化复现，提供最小手工复现步骤 + 说明原因，但不能跳过验证结论。
修复完成 ≠ 可以合入。必须回到原 feedback source 确认。
| Feedback source | 修复后动作 |
|---|---|
| 本地猫 reviewer | @reviewer 发送修复确认请求；等 reviewer 明确放行当前 SHA |
| cloud / GitHub review | 在 GitHub 回复或标注修复证据，push 新 SHA 后只重新触发 cloud review，等 PR tracking / review feedback；不要 @ 本地旧 reviewer |
| CI / PR check | 修复后 rerun/check gate；若只是外部 check gate，不需要本地 reviewer 续签 |
| operator / 愿景级 feedback | 回读原始需求；需要价值取舍时带 Decision Packet 给operator |
❌ 错误：cloud P2 修复 → @ 本地旧 reviewer 续签 → 等 cloud → 再 @ 本地 reviewer
✅ 正确：cloud P2 修复 → re-trigger cloud review → 等 PR truth source；local peer 只在非 cloud 行为 delta / scope 扩大时介入
确认信格式（简要，详细版见 refs/ 如有需要）：
## 修复确认请求
| # | 问题 | 状态 | Red→Green |
|---|------|------|-----------|
| P1-1 | {描述} | ✅ | {test file}: FAIL → PASS |
| P2-1 | {描述} | ✅ | {test file}: FAIL → PASS |
测试结果：pnpm test → {X} passed, 0 failed
Commit: {sha} — {message}
请确认修复，确认后执行合入。
修复完成后（F160 Phase C）：
cat_cafe_update_task 状态改为 doneremote review 修了 P1/P2 → 必须 re-trigger remote review，不能自判通过直接合入，也不能把 cloud gate 投射成本地旧 reviewer。
教训（F121 狼人杀）：reviewer 只看代码没打开浏览器，author 连续 9 轮瞎猜修都没被发现。
涉及 UX/前端/交互的改动，reviewer 必须实际打开浏览器操作验证，不能只看代码和测试输出。
验证清单：
1. 打开浏览器（Playwright/Chrome MCP）访问对应页面
2. 按 AC 或 bug 复现步骤实际操作
3. 截图/录屏作为验证证据
4. 如果和设计稿（.pen）有出入，标注差异
没有浏览器验证的前端 review = 走过场。
Reviewer 在 review 过程中发现 author 触发以下任一条件，可直接发起 TAKEOVER（详见 shared-rules §18）：
触发后：在 thread 显式宣布 TAKEOVER → 原 author 停止试错 → 你或另一只猫接手修复。接管猫不得自审，需由另一只猫 review。
| 错误 | 正确做法 |
|---|---|
| 边读边改，没读完 | 读完整反馈，分类后再动手 |
| 有不清晰的问题但先改清晰的 | 全部澄清后再统一动手 |
| 没写 Red 测试直接改代码 | 先写失败测试，确认红灯，再修 |
| 修完自判"对了"直接合入 | 必须回给 reviewer 确认 |
| 全盘接受，零 push back | 有技术理由必须说出来 |
| 愿景级问题用代码 patch | STOP，升级operator，不要硬修 |
| 云端 P1 修完不 re-trigger | 必须重新触发remote review |
| 前端改动只看代码不开浏览器 | 涉及 UX 必须打开浏览器实操验证 |
| 只修 reviewer 指的那一个点（补锅匠） | 先判 failure mode 是否同类，是则 audit 本 PR diff 全扫再修 |
| 同型 finding 打到 R5+ 还在逐轮修 | 第 3 轮就停，升级 plan/spec 作者补状态机（≥3 轮升级规则）——代码层修不掉 spec 层的洞 |
| Skill | 关注点 | 时机 |
|---|---|---|
quality-gate | 自己检查自己（spec + 证据） | 提 review 之前 |
request-review | 发出 review 请求 | 自检通过之后 |
| receive-review（本 skill） | 处理 reviewer 的反馈 | 收到 review 之后 |
merge-gate | 合入前门禁 + PR + remote review | reviewer 放行之后 |
Reviewer 在 review 期间创建的沙盒：
request-review 约定的路径 /tmp/cat-cafe-review/{review-target-id}/{reviewer-handle}为什么不让 reviewer 自己清理：reviewer session 在放行后结束，下次唤醒时 context 已换， 根本不记得自己在 /tmp 留了什么。merge-gate 是唯一确定性终态。
Reviewer 放行（"LGTM"/"通过"/"可以合入"）→ 直接加载 merge-gate skill（SOP stage merge）。不要停下来问operator（§17）。