Menu
跨猫传话/交接的五件套结构（What/Why/Tradeoff/Open/Next）。 Use when: 交接工作给其他猫、传话、写 review 信。 Not for: 自己的任务、不涉及其他猫的工作。 Output: 结构化交接信。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | cross-cat-handoff |
| description | 跨猫传话/交接的五件套结构（What/Why/Tradeoff/Open/Next）。 Use when: 交接工作给其他猫、传话、写 review 信。 Not for: 自己的任务、不涉及其他猫的工作。 Output: 结构化交接信。 |
| triggers | ["交接","传话","handoff"] |
Core principle: 交接不能只写"改了什么"。没有 Why = 接手方无法判断 = 低效协作。
每次交接/传话/review 请求必须包含：
| # | 项目 | 说明 | 示例 |
|---|---|---|---|
| 1 | What | 具体改动或决策 | "新增了 CAS Lua 脚本保护状态更新" |
| 2 | Why | 为什么这样做 | "内存 store 返回活引用导致竞态" |
| 3 | Tradeoff | 放弃了什么备选 | "考虑过乐观锁，但 Lua 更原子" |
| 4 | Open Questions | 还不确定的点（分技术/价值两类） | "keyPrefix 行为需要验证"（技术）/ Decision Packet（价值） |
| 5 | Next Action | 希望接手方做什么 | "请 review 这三个文件的改动" |
BEFORE 发送交接/传话/review请求:
1. SCAN: 检查消息是否包含五件套
2. MISSING: 识别缺失项
3. BLOCK: 如有缺失，阻止发送并提示补充
4. PASS: 全部包含，允许发送
Author 猫准备写: "@ Reviewer 我改完了三个文件，帮我 review"
⚠️ BLOCKED — 交接缺失必要信息
缺失项:
- ❌ Why: 为什么要改？
- ❌ Tradeoff: 有没有考虑过其他方案？
- ❌ Open Questions: 有什么不确定的？
- ❌ Next Action: 希望 review 什么重点？
请补充五件套后再发送。
Author 猫准备写: "@ Reviewer 我加了 CAS 保护，因为发现竞态问题"
⚠️ BLOCKED — 交接缺失必要信息
已有:
- ✅ What: 加了 CAS 保护
- ✅ Why: 发现竞态问题
缺失:
- ❌ Tradeoff: 为什么选 CAS？考虑过其他方案吗？
- ❌ Open Questions: 有什么不确定的？
- ❌ Next Action: 希望 Reviewer 做什么？
请补充后再发送。
## 交给 Reviewer Review: ADR-008 S2 Retry + CAS
### What
新增 CAS Lua 脚本保护 InvocationRecord 状态更新：
- `CAS_UPDATE_LUA`: HGET 比对 + HSET 更新
- 修改 `RedisInvocationRecordStore.updateStatus()`
- 新增 `snapshotStatus` 在调用前保存原始状态
### Why
内存 store 的 `get()` 返回活引用，导致：
1. 读取 status 后，在比对前可能被其他请求修改
2. 原来的 CAS 逻辑比对的是已经被修改的值
3. 导致竞态条件：两个并发请求都能通过比对
### Tradeoff
考虑过的方案：
- **乐观锁（version 字段）**: 需要改 schema，影响面大
- **分布式锁**: 太重，且 Redis 单线程本身就是串行的
- **Lua CAS**: 选择这个，原子性由 Redis 保证
### Open Questions
**技术 OQ**（猫猫解决）：
1. `keyPrefix` 在 `eval()` 中的行为是否和普通命令一致？
2. 是否需要添加重试逻辑？
**价值 OQ**（如需 operator 拍板，附 Decision Packet——格式见 `refs/decision-matrix.md`）：
- （本次无）
### Next Action
请 review 这三个文件：
1. `RedisInvocationRecordStore.ts` - CAS Lua 实现
2. `InvocationRecordStore.ts` - snapshotStatus 逻辑
3. `invocation-flow.spec.ts` - 竞态测试用例
重点关注：
- Lua 脚本的原子性是否正确
- snapshotStatus 时机是否正确
- 测试是否覆盖竞态场景
✅ 检查通过 - 五件套完整
交给其他猫审查代码。
重点：
一只猫做到一半，另一只猫接手。
重点：
通知其他猫一个重要决策。
重点：
邀请其他猫讨论某个方向性问题（不是任务指派）。
特殊规则：
详见 feat-lifecycle skill 的讨论阶段（开放讨论模式）。
| 错误 | 问题 | 正确做法 |
|---|---|---|
| "帮我 review 这个" | 不知道该关注什么 | 说明 review 重点 |
| "我改完了" | 不知道改了什么/为什么 | 写明 What + Why |
| "按你说的改了" | 不知道改对了没 | 说明具体改了什么 |
| "遇到问题，你看看" | 不知道具体问题 | 描述问题 + 你的分析 |
复制此清单用于自检：
交接五件套自检:
- [ ] What: 具体改动/决策是什么？
- [ ] Why: 为什么这样做？约束/风险/目标是什么？
- [ ] Tradeoff: 放弃了什么备选方案？
- [ ] Open Questions: 还有什么不确定的？
- [ ] Next Action: 希望接手方下一步做什么？
receive-reviewworktree 开始collaborative-thinkingrefs/shared-rules.md §1review-notes/约定图发现方法论：进一个 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)。