# Three-Party Code Review

Runs a red-team, third-party and neutral review loop on finished code before release.

- Repository: https://github.com/iflytek/skillhub (5351 stars)
- Category: Git and review
- License: MIT
- Last updated: 2026-10-31
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add iflytek/skillhub --skill adversarial-review -g -a claude-code -y`
Codex: `npx skills add iflytek/skillhub --skill adversarial-review -g -a codex -y`
Cursor: `npx skills add iflytek/skillhub --skill adversarial-review -g -a cursor -y`
Gemini CLI: `npx skills add iflytek/skillhub --skill adversarial-review -g -a gemini-cli -y`

## Description

开发完成后的三方对抗式代码评审闭环：蓝军（敌意审查，须给证据链）→ 第三方（独立审计，不信双方文档、只读代码，专找"修改引入的新缺陷"并稽核蓝军漏审的维度）→ 中立裁定（逐条采纳/驳回、审查双方共同前提）。当用户说"蓝军评审""第三方复核""对抗性审查""红蓝互搏""三方评审""交叉验证""发布前审查""帮我挑刺""adversarial review""red team review""pre-release review""critique this""find bugs in my code"或要求提升代码质量、准备发布前把关时使用。也适用于用户想把当前会话变成"多个 Agent 互搏"来提升代码水平的场景。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 三方对抗式代码评审（Blue Team / Third Party / Adjudication）

## 这个 skill 要解决什么

单人或单 AI 写代码，最大的风险不是"不会写"，而是：

1. **用未验证的乐观假设说服自己推迟修复**（"这个兜底应该够了吧"）；
2. **测试提供假安全感**（测试全绿，但功能其实早坏了）；
3. **为了修 A 而引入 B**（新写的修复代码本身没被独立审视）。

这三个问题**靠"再仔细看一遍"解决不了**, , 写代码的人和审代码的人是同一个，就一定会为自己辩护。只能靠**结构化的对抗关系**：

| 角色 | 立场 | 硬性约束 |
|---|---|---|
| **蓝军** | 敌意审查, , 假设代码会出事，去**证明** | 每条结论必须附证据链（`文件:行号` / 实测命令 / 上游源码）；🔴/🟠 必须是**实测**结论，仅凭推理最高 🟡；禁止空话 |
| **第三方** | 独立审计, , **不信任任何一方文档**，直接读代码 | 逐条复核"声称修了的是否真修了"、**专找修改引入的新缺陷**、并稽核蓝军**漏掉了哪些维度** |
| **中立裁定** | 对双方结论**逐条采纳 / 驳回 / 改级** | 必须由**与蓝军不同的 agent** 担任；当事人不能当法官 |

**关键不是"多找两个 AI 看看"，而是顺序与互不信任**：第三方不信开发团队，裁定方不信蓝军和第三方。任一环节缺失，闭环就破。

### 配套文件（按需读取）

- **`references/review-dimensions.md`**, , **完整质量维度清单（19 项）**。第 0 步按改动类型选维度时必须读，否则审查会漏掉大片区域。
- **`references/prompt-templates.md`**, , **三个角色的完整提示词模板 + 占位符约定 + 「设计要点」表（改模板前必读）**。第 1/2/3 步派发子代理时直接取用，不要临时自编。
- **`references/quickstart.md`**, , 面向用户的上手说明（档位选择、什么时候不该用它）。
- **`examples/sample-review.md`**, , 一次真实评审的产出样例。

> ⚠️ **能力边界（必须向用户如实说明）**
> 子代理与主代理通常是**同一模型**，这不是真正独立的第三方。其价值来自**角色约束 + 强制证据**，而非"另一个 AI 的观点"。
> - ✅ 能有效抓出：代码级错误、逻辑漏洞、测试造假、自相矛盾、遗漏分支、声明与实现不符；
> - ❌ 抓不出：**双方共有的知识盲区**（例如对某个上游行为的一致误解）。若某个结论依赖外部系统行为，必须要求**实测验证**，而不是两个 agent 互相点头。
>
> 向用户汇报时，不要说"经独立第三方验证无误"，要说"经同模型不同角色的对抗审查"。

> 🔁 **降级模式（宿主无子代理能力时）**
> 若宿主不提供 `subagent`，只能由**同一个 agent 串行扮演三角色**。此时：
> - 独立性**已被显著削弱**，第 2、3 步的价值大幅下降；
> - 必须在报告开头显式声明"本次为降级模式，角色由同一 agent 串行扮演"；
> - 不得使用"独立复核""第三方验证"等措辞；
> - 有条件时优先换一个有子代理能力的宿主，而不是将就。

---

## 执行流程

### 第 0 步：确定档位、范围与维度

先问用户或从上下文判断档位（默认**标准档**）：

| 档位 | 配置 | 相对成本 | 适用 |
|---|---|---|---|
| **轻档** | 1 个蓝军（聚焦选定维度）| ~1x | 小改动、时间紧 |
| **标准档**（默认）| 蓝军全量 → 第三方复核 → 中立裁定，共 3 轮 | ~3x | 一般功能版本 |
| **重档** | 标准档 + 多路子代理并行交叉验证（按维度分组并行审）| ~5-8x | 发布前、重大重构、涉及上游兼容 |

（~Nx 为相对一轮蓝军审查的 token 经验估计，未经精确计量。）

**必做四件事**：

The rest: https://github.com/iflytek/skillhub/blob/HEAD/builtin-skills/skills/adversarial-review/SKILL.md