senior-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Senior Review — 双人独立高级复核

派两名独立复核子代理:**Reviewer A 判改动纪律与可维护性**,**Reviewer B 判影响半径、边缘情况与回归安全**。主循环综合两份报告,不得削弱任何一方的 verdict。本 skill 与语言/框架/仓库宿主无关;它**不替代**项目已有的功能、安全、领域或发布门禁。

---

## 0 · Claude Code 执行机制(先读这节,否则这个 skill 跑不起来)

1. **派发方式=`Agent` 工具**,不是让主循环自己扮演两个角色。
2. **两个 `Agent` 调用必须写在同一条消息里**——同消息内的多个工具调用才会真并发;分两轮发就退化成串行,还平白多一次上下文污染的机会。
3. **两名 reviewer 一律 `model: opus`(Opus 5)+ `effort: high`,这是默认档,不是可选项。**
   - 派发时必须显式写出 `model` 与 `effort`,**禁止省略让子代理静默继承主循环模型**。
   - 依据:owner 20260726 裁决——"对抗复核可以用 opus 5(high),但是你永远是最终验收和决策,opus 5 是可以的,4.8 不可以"。**Opus 4.8 明令禁用**。
   - 降档只有一种合法情形:owner 当场明示。省 token 不构成降档理由——**复核是这套流程唯一的质量闸门,降档等于关闸**。
   - 终审与最终决策**永远在主循环**,不随模型下放(见 §0.6)。
4. **只读靠 prompt 硬约束**:`Agent` 派出的子代理默认拥有写工具。派发时必须在 prompt 里写死:"你是只读复核员,禁止 Edit/Write 任何产品源码或测试;可以跑非破坏性测试、读历史、读消费方、读 schema/配置/产物/运行时证据;findings 直接写在你的最终回复里(或只写到调用方指定的那一个 review 产物文件)。"
5. **结果走完成通知回来**。**禁止用 Bash/Read 去读子代理的 output JSONL transcript**——那是完整对话流,读一次就可能撑爆主循环上下文。等通知,或用 `SendMessage` 追问。
6. **主循环永远是终裁**。两份 verdict 是**证据**,不是合流/部署/发布的授权。项目与 owner 的既有权限规则始终有效。
7. **compact/resume 之后**:不要基于摘要续审。从原始复核包和不可变 target 重建;必要时先落一份 checkpoint 再压缩。

---

## 1 · 不可协商规则

1. 派发前先读:用户请求、验收标准、仓库/工单说明、**精确 review target**、完整变更集、相关测试。
2. 两名 reviewer 拿到**完全相同的原始素材和同一个 target**。**不得泄露**作者的自辩理由、另一名 reviewer 的发现、或你期望的 verdict。
3. 必须是两个**不同的子代理**。并发不可用时可排队串行,**绝不允许一个 reviewer 扮两个人格**。
4. 两名 reviewer 对产品源码与外部状态**只读**(见 §0.4)。
5. 每名 reviewer 在出 verdict **之前**必须重读任务与精确变更清单。compact/中断/交接之后,从原始包重建,不从早前摘要重建。
6. **不接受**作者自审、worker 自证、测试全绿、或"没看到明显失败"作为通过依据。
7. 任何 `AMEND`/`REJECT`/`INSUFFICIENT_EVIDENCE` 都**阻断接受**。禁止把冲突 verdict 平均成 PASS。
8. 实验规模匹配真实风险。不得为凑清单制造无关检查;判定某类别"排除"必须给具体证据。
9. 两份 verdict 都只是复核证据,**不构成**合流、部署、发布或改动外部系统的授权。
10. **给复核过程本身设界**:每条阻断性发现必须点名"违反了哪条现行不变量"+"最小修正是什么"。不得把一个缺陷变成开放式重设计、不得递归审计无关邻居、不得在没有可测量证据进展的情况下维持 AMEND 循环。
11. 命令、等待、重试、轮询、压力测试、外部依赖**一律要有超时与停止条件**。复核员不得为了找产品级 hang 而制造进程级 hang。

---

## 2 · 复核包(packet)——两名 reviewer 拿到的是同一份

- 用户可见的问题与预期行为(说人话一句);
- 验收标准 + 明确的非目标;
- 仓库/任务卡约束;
- **精确 target 身份**:Git base/head 与祖先关系;非 Git 时给不可变前后快照、patch 身份、产物哈希,或显式的未提交 diff 边界;
- 完整变更清单与变更集(能给文件列表与 diff 统计就给);
- 相关测试、迁移、生成文件、lockfile、配置、API/schema 变更;
- 可得时给"修复前可复现失败 / 修复后成功"的证据;
- 已知基线失败、源码树状态、明确排除在复核外的文件或产物。

缺料由 reviewer 在安全前提下自行取证。**只有真正不可得的产品决策或权限边界才问用户。**

---

## 3 · Reviewer A 派发词(改动纪律)—— 可直接复制

> 你是一名独立高级复核员,只读。判定这个改动**是否用最小充分、可读、可维护的实现解决了既定问题**。找出多余的文件、抽象、防御分支、兼容层、依赖、生成物噪音、重构、格式化或黑话,它们会掩盖真正的改动。
>
> 你必须:
> 1. 用一句白话陈述"要求的行为"是什么。
> 2. 核实 target 身份并逐项清点每个变更文件/产物。Git 场景核 base/head 祖先关系;其它场景核快照或 patch 完整性。
> 3. 把每个文件或逻辑 hunk 归为 `必需实现` / `必需验证` / `无关`。
> 4. **任何"无关"改动至少是 `AMEND`。**
> 5. 质疑不成比例的 diff,但不要设武断的行数上限。对每一个新增的层、helper、工厂、策略、注册表、适配器、依赖、fallback、公开接口,问:**"删掉它,哪一条现行验收标准会失败?"**
> 6. 只有当一个新抽象**同时**满足"服务于多个真实的当前消费方或已批准的边界""降低当前复杂度或副作用""比直写代码更易懂易测易删"时才接受它。
> 7. 每个防御分支都必须有可达的触发条件、明确的错误语义、独立证据、且不静默掩盖失败。
> 8. 检查控制流、状态变更、命名、重复事实源、错误处理、回滚/删除路径、注释的维护成本。
> 9. 能安全跑就独立跑窄范围相关测试,发现必须绑到具体文件/符号/diff hunk/产物/命令输出。跑不了就做最强的安全静态或产物检查,并**明说证据缺口**。
> 10. 不提风格偏好,不要自己搞过度工程。
> 11. 如果 target 纠缠到无法可靠审计,提出最小的行为保持切片并返回 `REJECT`;**不要假装部分检查覆盖了整体**。
> 12. **检测放大**:把"建议的修正"与"原始缺陷"在文件、接口、状态、概念四个维度上比大小。任何一维在没有现行验收要求支撑下变大,就归类为 scope creep。**不要为了修一个具体 case 而要求一个通用框架。**
> 13. 多轮 AMEND 时,检查**整个修正后的累计范围**,但把发现分成 `本次修正引入` / `此前既有` / `无关新发现` 三类。只有前两类可以阻断本 target,除非无关新发现是"恰好落在本次变更旅程上的 P0/P1"。
>
> 输出格式见下方 §5,verdict 取 `PASS`/`AMEND`/`REJECT`/`INSUFFICIENT_EVIDENCE` 之一。

---

## 4 · Reviewer B 派发词(影响半径与边缘情况)—— 可直接复制

> 你是一名独立高级复核员,只读。**假设局部实现是对的**,重建它的直接与间接影响半径,主动探索现实的边缘情况,判定这个改动是否会让消费方、数据、授权、配置、打包或运行时行为发生回归。
>
> 你必须:
> 1. 用白话陈述"被改变的不变量"和受影响的用户/系统旅程。
> 2. 建影响地图,覆盖:调用方与消费方 / 公开接口与兼容性 / schema 与持久化 / 迁移与回滚 / 授权与隔离边界 / 并发与重试 / 缓存与后台任务 / 配置与密钥 / 依赖与供应链 / 性能与容量 / 打包·运行时·平台变体 / 可观测性与失败语义。每一类标 `受影响` / `已凭证据排除` / `未知`——**任一高风险类别为"未知"即阻断 PASS**。
> 3. 检查真实用法与依赖方向,**不得只看被编辑的模块就推断安全**。
> 4. 按现实风险切分边缘情况:
>    - 空、null、畸形、重复、陈旧、边界、超大输入;
>    - 权限、角色、租户、门店、归属不匹配;
>    - 并发、重试、乱序、部分失败、超时、重启、回滚路径;
>    - 新旧 schema、版本、平台、语言环境、时区、离线、降级依赖路径;
>    - 首次运行、长会话、重复使用、恢复行为。
> 5. 可安全执行时,对最高风险路径做**聚焦的手工探索测试**,记录 setup/动作/观察/证据。**至少跑通一个相邻消费方或用户旅程**;没有就展示你的消费方搜索过程。关键路径跑不了且缺口影响验收,返回 `INSUFFICIENT_EVIDENCE`。
> 6. 把有效的手工发现转成**有界的自动回归要求**——仅当它确定性、保护持久不变量、修复前能失败修复后能通过、维护成本稳定。**你不得自己改产品测试**:由作者在新 target 上加最小测试,再由一名全新 reviewer 独立验证。一次性视觉噪音、环境意外、纯臆测不要求自动化。
> 7. 检查测试断言的是**外部可见行为**而非实现细节,且真能抓住一个合理的回归。
> 8. **要求回归对称性**:测试或等价基线证据必须"修复前复现原失败、修复后通过";反向权限、迁移/回滚、并发、恢复这些高风险路径需要对应证据。
> 9. 明确点出"未被测试覆盖的风险",但不要为消除低概率臆测而扩大实现范围。
> 10. 优先选最小的能产出证据的实验。当剩余风险已被同一不变量覆盖、或属于另一个已批准任务时,停止加 case。
> 11. 每个新依赖:先问现有能力够不够,再查来源、维护状况、许可证兼容性、已知漏洞、体积与运行时成本。
> 12. **凡改动触及并发、事务、锁、租约、队列、worker、异步回调、取消、关闭、重试、资源归属,必须建活性地图**:列资源与持有者;记录锁/事务的获取顺序与释放路径;找出"持有锁/事务/许可/文件句柄/连接/租约时进行的等待";识别循环等待、丢失唤醒、饥饿、优先级反转、重试风暴、租约抢占、重复持有、关闭/重启风险;为每个循环或 worker 点名"可观测的进展度量"。
> 13. **区分失败模式**:`死锁`=因循环或未释放的持有导致无人能进展;`活锁`=参与者不断改状态/重试但用户可见操作永不完成;`饥饿`=某个合法参与者可被无限期推迟;`慢但有界`=完成时间有可证明上界且有可见进展。**光有超时不等于死锁。**
> 14. 需要时给出有界的活性证据:确定性调度或聚焦压测,带硬 deadline、进展断言、取消/关闭检查、测试后残留审计。**避免靠 sleep 的脆弱证明**,优先 barrier、假时钟、受控执行器、数据库锁超时、事件轨迹。
>
> 输出格式见下方 §5,verdict 取 `PASS`/`AMEND`/`REJECT`/`INSUFFICIENT_EVIDENCE` 之一。

---

## 5 · Finding 格式与 verdict

每名 reviewer **先出 findings**,按严重度排序:

- `问题`:一句白话。
- `影响`:具体的用户/数据/安全/运维/维护后果。
- `证据`:target 身份 + 文件与符号、diff hunk、产物、消费方路径、命令、日志、截图或运行时观察。
- `最小修复`:保持任务边界的最窄修正。

禁止:黑话、冗长的过程叙述、重复摘要、多个未选定的重设计方案、无支撑的未来臆测。

**严重度**
- `P0`:数据丢失/损坏、安全或授权突破、不可恢复的生产故障、或**伪造的复核范围**。
- `P1`:行为错误、大概率回归、消费方或迁移被打断、隐藏的大范围语义变更、关键错误被掩盖。

From 0fuk/OpenACCP, MIT.

More from 0fuk/OpenACCP