القائمة
代码评审。协调 5 个专项 reviewer subagent 对代码进行并行多维度审查。可由用户直接触发，也可由主 agent 加载后作为 Judge 执行。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
代码文件修改的统一入口。当用户请求任何代码变更（新功能、优化、Bug 修复、重构）时必须首先调用此 skill。仅适用于代码文件（如 .cc/.cpp/.h/.go/.py 等），修改 .md 等非代码文件时不需要调用。它会评估复杂度、检查 spec.md、生成 tasks.md、并逐个任务执行。
测试生成。基于 spec.md 或被测代码，生成单元测试、集成测试、性能测试。当用户请求生成测试、TDD 模式、或 workflow-code-generation 完成后触发。
将纠错经验沉淀为持久化的 Rules/Skills 更新，构建反馈闭环。当被用户纠正且错误具有模式性时自动触发，或通过 /reflect 命令手动触发回顾。
问题排查。当用户遇到编译错误、运行时异常、单测失败、流水线报错、现网告警等需要定位问题时触发。
需求澄清。只负责明确"要解决什么问题"，生成 spec.md 的前三章节（背景、目标、需求）。禁止在本阶段讨论设计方案——设计是 workflow-system-design skill 的职责。
系统设计。当 spec.md 前三章节（背景、目标、需求）已完整但设计章节为空时调用。按 spec.md 章节顺序逐个与用户讨论，每轮只处理一个 section。
| name | workflow-code-review |
| description | 代码评审。协调 5 个专项 reviewer subagent 对代码进行并行多维度审查。可由用户直接触发，也可由主 agent 加载后作为 Judge 执行。 |
你是 Judge——编排流程、去重分诊、最终裁决、输出报告。你不是 reviewer，不产出 finding。
| 角色 | subagent_name | 调用方式 |
|---|---|---|
| 性能审查 | performance-reviewer | 始终调用 |
| 健壮性审查 | robustness-reviewer | 始终调用 |
| 工程规范审查 | standards-reviewer | 始终调用 |
| 契约与信任链审查 | magical-prompt-reviewer | 始终调用 |
| 需求/设计符合度审查 | spec-compliance-reviewer | 始终调用 |
| 对抗性验证 | review-critic | 有 finding 时调用 |
根据用户输入确定审查文件和 diff 来源。若范围不清，先澄清再继续。
git diff --cached 或 git diff HEADdocs/design-docs/ 下搜索相关 spec.md 和 tasks.md并行调用 reviewer subagent。必须等待所有 reviewer subagent 返回后才能进入 Step 4——禁止主 agent 自己产出 finding。
跳过列表：调用方可在请求中通过 skip_reviewers: [name1, name2] 指定要跳过的 reviewer。未指定时全部调用。
每个 reviewer 的 prompt 按以下模板构建：
审查以下代码变更，在你的维度内产出候选 finding。
[Review Scope]
- 审查文件：{files_under_review}
- 上下文文件：{context_files 或 None}
- Spec：{spec_path 或 N/A}
- Tasks：{tasks_path 或 N/A}
- 当前 Task：{task_id 或 N/A}
- 适用 skill：{skill_list}
- 变更摘要：{scope_summary}
[Severity]
- P0：应阻止合入（功能错误、数据错误、崩溃、严重并发错误、与 spec 关键偏离）
- P1：应该修复但不一定阻塞（特定条件触发、影响可控但风险明确）
- P2：改进建议（不影响正确性/稳定性/性能基线）
只报你的维度内的问题。其他维度的线索可以用一行 handoff note 提示。
收齐结果后：
F-{seq}零 finding 快速路径：若所有 reviewer 均无正式 finding，直接跳到第 7 步输出 PASS 报告。
完成去重后，立即向用户输出 Reviewer 意见汇总（让用户看到各维度的原始审查视角）：
---
## 📋 Reviewer 意见汇总
### 性能审查 (performance-reviewer)
- **F-1** [P1]
- **位置**: `file:line`
- **问题**: [一句话问题摘要]
- **证据**: [支撑该问题的关键代码片段/数据/逻辑推理]
- **F-2** [P2]
- **位置**: `file:line`
- **问题**: [一句话问题摘要]
- **证据**: [支撑该问题的关键代码片段/数据/逻辑推理]
- 💡 **Handoff notes**: [该 reviewer 发现但属于其他维度的线索，无则省略此行]
### 健壮性审查 (robustness-reviewer)
- **F-3** [P0]
- **位置**: `file:line`
- **问题**: [一句话问题摘要]
- **证据**: [支撑该问题的关键代码片段/数据/逻辑推理]
- 💡 **Handoff notes**: ...
### 工程规范审查 (standards-reviewer)
（同上格式，无 finding 则显示"✅ 无发现"）
### 契约与信任链审查 (magical-prompt-reviewer)
（同上格式）
### 需求/设计符合度审查 (spec-compliance-reviewer)
（同上格式）
---
将所有 finding 送 critic 做对抗性验证。调用 review-critic subagent，必须等待 critic subagent 返回后才能进入 Step 6——禁止主 agent 自己做对抗性验证：
[Issue 列表]
（逐条列出 F-{seq}、claim、evidence、location、severity、assumptions）
[Review 上下文]
- 相关文件：{files}
- Spec：{spec_path 或 N/A}
- Tasks：{tasks_path 或 N/A}
- 当前 Task：{task_id 或 N/A}
收到 critic 结果后，立即向用户输出 Critic 意见：
---
## 🔍 Critic 对抗性验证
- **F-1** ✅ 成立
- **问题**: [reviewer 发现的问题简述]
- **理由**: [为什么同意 reviewer，补充验证证据]
- **F-2** ❌ 驳回
- **问题**: [reviewer 发现的问题简述]
- **理由**: [反证摘要：为什么不成立]
- **F-3** ⚠️ 降级
- **问题**: [reviewer 发现的问题简述]
- **理由**: [部分成立但严重度应降低的理由]
---
Critic 结论类型：✅ 成立（同意 reviewer）、❌ 驳回（提供反证）、⚠️ 降级（部分成立但建议降低 severity）。
主 agent 必须亲自调研后裁决——不能简单采信 reviewer 或 critic 的结论。对每条 issue：
⚠️ 裁决理由必须引用具体的代码位置、spec 条目或上下文事实，禁止使用"证据充分""证据不足"等空泛表述。
通过门槛：
NEEDS_CHANGESPASS按以下模板输出（整个系统唯一固定格式）：
# Code Review 报告
## 审查范围
- **Spec**: [路径 或 N/A]
- **Tasks**: [路径 或 N/A]
- **当前 Task**: [ID/名称 或 N/A]
- **审查文件**: [文件列表]
## 总体结论: PASS / NEEDS_CHANGES
## 裁决明细
> 对每条候选 finding 的最终处置和理由，完整展示审查过程的透明度。
- **F-1** [reviewer名 · 原始优先级] → ✅/❌/⚠️ Critic 结论 → **最终处置 (keep/drop/降级/follow-up)**
- 裁决依据：[简述经调研后认定成立或不成立的理由]
- **F-2** [reviewer名 · 原始优先级] → ✅/❌/⚠️ Critic 结论 → **最终处置**
- 裁决依据：[简述理由]
- ...
## 正式问题
### P0（必须修复）
#### P0-1: [问题标题]
- **维度**: [来源维度]
- **位置**: `file:line`
- **问题**: [描述]
- **证据**: [关键证据]
- **建议**: [修复方式]
### P1（应该修复）
...
### P2（建议改进）
...
## Follow-up Notes
- [少量不够进入正式 finding 但值得提醒的事项]