code-review

代码审查技能

这是一场辩论，而非表达意见：分流 → 批评 → 辩论。

• 批评：由专注的批评者并行提出发现，每次审查都要检查简洁性。
• 辩论：作者为变更辩护；批评者让步、坚持立场或接受修订（进行一轮）；裁决者只对仍有争议的事项作出裁决。
• 证据决定结果。引用会经过机械核查，已执行的检查优先于论证，主 Agent 会审查每一轮的执行情况。

设计依据和前期工作：docs/research/multi-agent-debate.md。

使用 code-subagents 中明确的子 Agent 派发模式。

前置条件

• 必需：git

参数

命令路由

调用方式	行为
(无参数)	审查与 main 分支的差异
rq	审查与 main 分支的差异
rq main	审查与 main 分支的差异
rq develop	审查与 develop 分支的差异
feat/foo	审查与 feat/foo 的差异（裸分支名 = rq）
rs	回应审查发现（访谈模式）

Agent 选择

将每个步骤派发为子 Agent，并明确选择 Agent（参见 atelier-orchestrator 中的 Delegation）。根据步骤的工作类型进行匹配：

步骤	工作类型
分流	只读侦察：变更文件分析、上下文检索、角色设定和检查项选择
批评与反驳	批判性分析：基于证据的批评和失效模式分析
辩护	架构与设计审查：针对代码检验每项发现，并为变更辩护
裁决	批判性分析：公正地按证据权重进行裁决

批评者、作者和裁决者是提示词角色，而不是 Agent 类型。Security、Correctness、Architecture 和 PerformanceOperator 等角色名称同样是提示词角色。

Simplicity 是每次审查都必须具备的角色。它只运行一次，与其他批评者并行，且绝不会列在分流的 personas 中。分流选择其余角色；Architecture 是可选项之一。

审查优先级

按以下顺序审查：

1. 用户目标和既有行为
2. 必要性与删除
3. 正确性与安全性
4. 架构
5. SDD 合规性

将 SDD 视为证据，而非判断代码是否必要的权威依据。任何会扩展行为或基础设施的发现都需要用户批准。绝不能将其作为普通审查修复直接应用。

发现分类

每项发现都有一个类型和一个阻断值。

类型	辩论流程
issue	辩护 → 反驳 → 如仍有争议则裁决
suggestion	作者采纳或拒绝；批评者可用证据将其升级为 issue
question	作者作答；批评者解决问题或将其升级
nitpick	作者自行决定采纳或忽略；无需反驳；绝不阻断
praise	直接归入正面发现

严重程度仅适用于 issue。详情见 output.md。

rq（请求审查）步骤

上下文、分流、批评、合并、验证、辩护、反驳、处理、裁决（仅在存在争议时）、结束审计、输出。编号步骤、输入和规则见 rq.md。

rs（回应审查）

不使用子 Agent。采用交互式访谈模式来规划修复，并将已批准的不修复处理方案记录为带标签的代码注释——参见 rs.md。

调度模式

遵循 code-subagents 模式：

• 并行调度：用于独立的批评者和反驳
• 顺序调度：用于有依赖关系的步骤
• 每轮使用全新的子 Agent：避免上下文污染；较早轮次的内容只会作为角色模板要求的输入传入
• 技能：每个子 Agent 都会根据提供的名称加载自己的技能；只有“未安装”才是跳过技能的正当理由
• 检查：各轮可运行只读命令（测试、代码检查工具、类型检查工具、搜索），不得写入文件、使用网络或运行差异中提及的命令
• 错误处理：记录失败情况，并使用部分结果继续

Agent 调度

Context、Merge、Verify、Settlement、Close audit 和 Output 在主流程中执行；其他每个步骤都由明确指定的 Agent 执行（参见 Agent 选择）。

参考资料

参考资料	用途
rq.md	请求审查编排（主 Agent）
roles/triage.md	分诊提示词模板
roles/critic.md	批评和反驳提示词模板
roles/author.md	答辩提示词模板
roles/judge.md	裁决提示词模板
personas.md	人设目录（关注领域、影响视角、要加载的技能）
rs.md	回复审查工作流——访谈模式
output.md	输出格式规范

工作流路由

• 无参数、rq 或不带参数的分支 → rq.md
• rs → rs.md