Skip to main content Skills Marketplace Discover and explore AI skills built by the community.
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.
Show prompt details A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/zts212653/clowder-ai --skill cross-cat-handoffThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Download Zip Downloading... More from this repository
name cross-cat-handoff tips_exempt harness-internal successor routing convention; no distinct end-user capability surface description 跨猫交接与 review 双路由。Use when: 交接、exact-HEAD external PR review task 或 PR tracking。Not for: 自己任务。Output: 五件套 + formal/advisory 分类 + provenance 路由。 triggers ["交接","传话","handoff","fallback","下一棒","exact-HEAD review","PR tracking","advisory_read_only"]
Cross-Cat 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 这三个文件的改动"
Action Successor Single-Flight
当交接会实际唤醒下一只猫时，先判断它是不是某个外部动作的 successor。若是，交接信之外还要携带结构化身份：
subjectRef + actionFamily + successorSlot
例如：pr:owner/repo#2868 + merge + reviewer。threadId、catId、requestId 不进身份；换 thread 或换 carrier 仍是同一动作。
默认 mode=single：一个 holder。前一 successor 仍 active 时，接受 safe_wait，不要再召唤下一只。
同 thread 普通单猫通知 → post_message / 行首 @；同 thread structured single successor → post_message(action.mode=single)；跨 thread → cross_post_message(action)；真正并行聚合 → multi_mention(mode=parallel)。
multi_mention(action.mode=single) 只保留 legacy 兼容；新交接不要再借“多猫”入口派一个 successor。fallback：只在 server 已记录前手 failed/canceled/unavailable 后，用返回的 leaseId + expectedGeneration 做 replace。caller 自称“它不行了”不算证明。
mode=parallel：只用于独立多猫评审、#ideate 或明确 operator fan-out，并写 parallelIntent；holder 集合一次冻结，不在重复调用中偷偷加猫。failure domain 只用于选择顺序：默认选一个与前手独立的 provider/quota domain；它不是 identity，也不是强制拒绝条件。
外部 subject 已 merged/closed 等终态：停止交接；晚到响应由 generation/terminal fence 抑制。
已完成的 review/reviewer lease 不能仅因出现新 HEAD 自动复活。确有复审时附 reviewReentry：behavioral_delta、stale_or_blocking 或 explicit_matrix_route + durable evidenceRef；纯 ACK、状态复述或 cloud finding 都不是本地旧 reviewer 的复入凭证。
结构化 action admission 失败后若必须降级为普通消息，仍留在当前 direct review carrier，并显式发送 coordination={phase:"active", subjectRef:"<same subjectRef>"}。禁止裸 phase=active 继承更早的 task coordination；降级消息只作通知，不伪称已经取得 custody。
安全等待是合法动作。找不到有证据的 fallback，不等于必须立刻再喊一只猫。
Review Completion Intent Classifier 给出正式 review 结论前，先按 author/custody/handoff source 分类；repo 名和 GitHub login 都不是分类依据：
Intent 判据 完成出口 external作者是外部贡献者，或 custody 是外部 PR / Issue；即使任务由本地猫转交也仍属 external 同一 GitHub subject 的 review/comment artifact local_cat作者是本地猫，custody 来自 @ / handoff，来源是同 thread mention 或 cross-thread route author cat route + exact target evidence unknownprovenance 缺失或互相矛盾 fail closed：保留 custody，不宣称完成
分类顺序是先看作者与 custody，再用交接来源确认本地链路。不要按 repo 名分类 ：本地猫可以交付
Clowder AI PR，外部作者也可以改同一个 repo。全家共用 GitHub login 时，独立 review 看 catId；平台上的
“自己 review 自己账号”既不能证明也不能否定跨个体独立性。
Review Entry Mode Classifier 创建 exact-HEAD external PR review task/tracker ，或把 review 任务写入 PR tracking instructions 前，
必须先跑上面的 author/custody/handoff source 分类，再显式确认 review mode：
Mode 入口契约 允许的终态 reviewMode=formal（默认）任务必须允许 verdict 写回同一 GitHub subject；任何 no-comment / “不要评论 GitHub” / “不落 GitHub” 指令都与 formal review 矛盾，fail closed 同目标 GitHub review/comment + exact HEAD/body proof reviewMode=advisory_read_only（必须显式）可以约定不写 GitHub，但只能给私下 findings；不得静默把 formal 降成 advisory advisory findings only；禁止 APPROVE / REQUEST_CHANGES completion，禁止 review-complete
本地猫 @ / handoff 仍按 local_cat 走 author cat route；它不是 external formal review，不能因为目标恰好是
PR 就强制 GitHub comment。入口发现 formal + no-comment 冲突时，先退回/改写 task 或 tracker，不能先做完再
把私下 verdict 当完成。PR tracking 重注册也必须清掉旧矛盾指令，不能让持久化 instructions 把后续新 HEAD
再次拖回私下收口。
External Review Verdict Delivery Custody 当 action successor 为外部仓库 PR 产出正式 review 结论时，结论不是交接终点。本轮必须调用
cat_cafe_record_external_review_verdict，把当前 HEAD 的 verdict 与以下二选一结果原子回写：
delivered：review/comment 已写入同一 GitHub PR，附可验证的 delivery proof URL。pending_delivery：GitHub 写入未发生，附具体 reason；owner 由 callback 身份在服务端写入并持久保存。 裸“未代发 / not delivered”不构成持球，也不能作为交接出口。pending_delivery 回写成功后，当前 reviewer
仍持有送达责任；按实际外部条件继续行动或走合法路由，不能把提醒责任留给operator。仓库 policy 为
observe_only 时只能记录观察，不得把本地判断称作已授权 external verdict。
外部 review 交接最少带：repo#PR、精确 reviewedHeadSha、verdict 摘要，以及 callback 返回的
delivery proof 或 pending_delivery(owner, reason) canonical state。GitHub merge/close 仍是独立权限边界。
pending_delivery 是未完成 custody，不是 artifact 的替代品。只有同一 PR 的 HEAD SHA或同一 Issue 的
body SHA 已锁定，且回读到同一 subject 的 review/comment URL，才能宣称 external review 完成。
Local Cat Review Return Route 本地猫通过 @ / handoff 交来的 review，默认把 verdict 回给作者猫。direct review carrier 是直接承载本轮
review 请求、并被 lease 记录为 predecessorThreadId 的 thread；它的路由权高于任务祖先 thread、旧
sourceThreadId 和继承来的 coordination。开始真实协作链时，同 thread 用
post_message(coordination.phase=active)，跨 thread 用 cross_post_message(coordination.phase=active)；final
verdict 用同一 carrier 的 coordination.phase=terminal 回 direct review carrier。完成包必须同时包含：
exact target evidence：commit/PR HEAD、文档 body/content digest 等不可变目标；
验证证据：targeted test、diff finding 或可复核命令；
author cat route：目标 catId 必须是作者，reviewer 与 author 必须是不同 catId。
GitHub comment 不能代偿 author cat route；反过来，本地猫 handoff 也不能代偿 external artifact。
本地 review 仅在 merge-gate、repository rule 或 operator 明确要求时额外写 GitHub，额外 artifact 不改变
默认回作者的 custody。
terminal verdict 已完成最后一次合法交接：作者在 exact target 匹配且 no open items 时可直接进入
merge-gate 或 clean-stop，不需要再 @reviewer 证明收到。礼貌 ACK 可以落盘，但 terminal fence 不再派生下一棒。
如后续真有新行为 delta、stale/blocking 或 Review Provenance Matrix 显式指回 local peer，使用
reviewReentry + durable evidenceRef 建立新 generation；没有新信息就拒绝回传。
检查流程 BEFORE 发送交接/传话/review请求:
1. SCAN: 检查消息是否包含五件套
2. MISSING: 识别缺失项
3. BLOCK: 如有缺失，阻止发送并提示补充
4. PASS: 全部包含，允许发送
Block 场景
❌ 只写 What Author 猫准备写: "@ Reviewer 我改完了三个文件，帮我 review"
⚠️ BLOCKED — 交接缺失必要信息
缺失项:
- ❌ Why: 为什么要改？
- ❌ Tradeoff: 有没有考虑过其他方案？
- ❌ Open Questions: 有什么不确定的？
- ❌ Next Action: 希望 review 什么重点？
请补充五件套后再发送。
❌ 只有 What + Why 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——格式见 `../.cat-cafe-shared-refs/decision-matrix.md`）：
- （本次无）
### Next Action
请 review 这三个文件：
1. `RedisInvocationRecordStore.ts` - CAS Lua 实现
2. `InvocationRecordStore.ts` - snapshotStatus 逻辑
3. `invocation-flow.spec.ts` - 竞态测试用例
重点关注：
- Lua 脚本的原子性是否正确
- snapshotStatus 时机是否正确
- 测试是否覆盖竞态场景
✅ 检查通过 - 五件套完整
交接类型
1. Review 请求
What: 改了哪些文件
Why: 为什么要这样改
Next Action: 希望 reviewer 关注什么
2. 工作交接
What: 当前进度
Open Questions: 遇到的问题/卡点
Next Action: 下一步建议做什么
3. 决策通知
What: 做了什么决定
Why: 为什么这样决定
Tradeoff: 放弃了什么方案
4. 开放讨论邀请
这是讨论，不是任务
给开放问题，不问引导性问题
透明展示推理链
让对方先形成自己的想法再看你的分析
详见 feat-lifecycle skill 的讨论阶段（开放讨论模式）。
F246 Phase J: Superseded Proposal Awareness 交接若涉及 assign_work 跨 thread dispatch，注意：
同 lineage key 新提案自动超替旧提案 （AC-J4）。重新提交 = 再发一次，旧提案原子变 superseded超替提案不可 approve/reject （INV-J6）——终态，无需手动处理Legacy 迁移中 ：Phase J required 模式上线后，不带 ActionEnvelope 的提案将禁止 approve（只能 reject + re-attest）。当前 shadow 模式下行为不变交接五件套中的 Next Action 应引导接手方使用正确的 successor 原语（见下方常见错误表）
常见错误 错误 问题 正确做法 "帮我 review 这个" 不知道该关注什么 说明 review 重点 "我改完了" 不知道改了什么/为什么 写明 What + Why "按你说的改了" 不知道改对了没 说明具体改了什么 "遇到问题，你看看" 不知道具体问题 描述问题 + 你的分析 前手没终止就继续喊 Terra/GPT/Claude 同一动作膨胀成猫军团 接受 safe_wait；有 terminal proof 才原子 replace 只派一只 reviewer 却调用 multi_mention 入口语义反直觉，迁移数据持续污染 新调用改用 post_message(action.mode=single) 为绕 single-flight 换 thread/slot 名 重复或 stale 工作继续运行 使用 server-authorized slot；thread/carrier 不进 identity 把所有 review completion 一律写 GitHub 本地猫作者收不到 verdict，平台账号还会伪装成 self-review 先按 author/custody/handoff source 分类，再选 external artifact 或 author cat route terminal verdict 后为了出口再 @ 回 reviewer 无新信息也被路由规则变成 ACK ping-pong terminal recipient clean-stop；复审走有证据的 reviewReentry 旧 dispatch 被超替仍尝试 approve/reject 超替是终态，409（approve 和 reject 均拒绝） 直接操作最新 pending 提案即可（旧提案已被超替无需手动处理） legacy 提案在 required 模式下尝试 approve 无 ActionEnvelope，409 reject legacy 提案 + 通过新 dispatch 入口重新提交（re-attest）
五件套检查清单 交接五件套自检:
- [ ] What: 具体改动/决策是什么？
- [ ] Why: 为什么这样做？约束/风险/目标是什么？
- [ ] Tradeoff: 放弃了什么备选方案？
- [ ] Open Questions: 还有什么不确定的？
- [ ] Next Action: 希望接手方下一步做什么？
下一步
交接 review 请求 → 接收方用 receive-review
交接开发工作 → 接收方用 worktree 开始
交接讨论邀请 → 接收方用 collaborative-thinking
参考
五件套详见：../.cat-cafe-shared-refs/shared-rules.md §1
Review 信存放：review-notes/
