ck:code-review

代码审查

以技术严谨性、基于证据的论断和验证为重，避免流于表面的回应，开展对抗性代码审查。每次审查都包含红队分析，主动尝试找出代码的问题。

输入模式

根据参数自动检测。如果有歧义或未提供参数，则通过 AskUserQuestion 提示。

输入	模式	审查内容
#123 或 PR URL	PR	通过 gh pr diff 获取完整 PR 差异
abc1234（7 个或更多十六进制字符）	Commit	通过 git show 查看单个提交的差异
--pending	Pending	通过 git diff 查看已暂存和未暂存的更改
(无参数，近期更改)	Default	审查上下文中的近期更改
codebase	Codebase	扫描整个代码库
codebase parallel	Codebase+	并行进行多审查者审计

模式判定详情： references/input-mode-resolution.md

无参数

如果调用时未提供参数，且上下文中没有近期更改，则使用 AskUserQuestion，标题为「审查目标」，问题为「你想审查什么？」：

选项	说明
待处理更改	审查已暂存／未暂存的 git diff
输入 PR 编号	获取并审查指定 PR
输入提交哈希	审查指定提交
扫描整个代码库	深入分析代码库
并行审计代码库	多审查者代码库扫描

核心原则

始终遵循 YAGNI、KISS、DRY。技术正确性优先于顾及他人感受。 诚实、直接、不留情面，直奔重点，简明扼要。

先验证，再实施。先询问，再假设。论断必须有证据。

实践

实践	适用时机	参考
规范符合性	根据计划／规范完成实现后、质量审查前	references/spec-compliance-review.md
对抗性审查	始终启用的第 3 阶段——主动尝试找出代码的问题	references/adversarial-review.md
接收反馈	反馈不明确、来自外部审查者或需要确定优先级时	references/code-review-reception.md
请求审查	任务完成后、合并前或问题陷入僵局时	references/requesting-code-review.md
验证关卡	声称完成、提交或创建 PR 之前	references/verification-before-completion.md
边界情况排查	实现后、审查前	references/edge-case-scouting.md
清单审查	发布前、/ck:ship 工作流、安全审计	references/checklist-workflow.md
任务管理式审查	多文件功能（3 个或更多文件）、并行审查者、修复周期	references/task-management-reviews.md

快速决策树

SITUATION?
│
├─ Input mode? → Resolve diff (references/input-mode-resolution.md)
│   ├─ #PR / URL → fetch PR diff
│   ├─ commit hash → git show
│   ├─ --pending → git diff (staged + unstaged)
│   ├─ codebase → full scan (references/codebase-scan-workflow.md)
│   ├─ codebase parallel → parallel audit (references/parallel-review-workflow.md)
│   └─ default → recent changes in context
│
├─ Received feedback → STOP if unclear, verify if external, implement if human partner
├─ Completed work from plan/spec:
│   ├─ Stage 1: Spec compliance review (references/spec-compliance-review.md)
│   │   └─ PASS? → Stage 2 │ FAIL? → Fix → Re-review Stage 1
│   ├─ Stage 2: Code quality review (code-reviewer subagent)
│   │   └─ Scout edge cases → Review standards, performance
│   └─ Stage 3: Adversarial review (references/adversarial-review.md) [ALWAYS-ON]
│       └─ Red-team the code → Adjudicate → Accept/Reject findings
├─ Completed work (no plan) → Scout → Code quality → Adversarial review
├─ Pre-landing / ship → Load checklists → Two-pass review → Adversarial review
├─ Multi-file feature (3+ files) → Create review pipeline tasks (scout→review→adversarial→fix→verify)
└─ About to claim status → RUN verification command FIRST

三阶段审查流程

第 1 阶段 — 规范符合性（加载 references/spec-compliance-review.md）

• 代码是否符合请求内容？
• 是否有遗漏的要求？是否有缺乏依据的额外内容？
• 第 2 阶段开始前必须通过

第 2 阶段 — 代码质量（code-reviewer 子 Agent）

• 仅在规范符合性通过后运行
• 检查标准、安全性、性能和边界情况

第 3 阶段 — 对抗性审查（加载 references/adversarial-review.md）

• 第 2 阶段通过后运行，并受范围门槛限制（文件数 <=2、代码行数 <=30 且不涉及安全文件时跳过）
• 在锚定上下文（运行时、框架、上下文文件）的基础上启动对抗性审查者
• 查找：安全漏洞、错误假设、资源耗尽、竞态条件、供应链问题、可观测性缺口
• 每项发现输出以下判定：接受（必须修复）／驳回（误报）／延期（GitHub issue）
• 严重发现会阻止合并；重新审查时采用仅检查修复差异的优化方式

接收反馈

流程： 阅读 → 理解 → 验证 → 评估 → 回复 → 实施 不要敷衍认同。实施前先验证。若反馈有误，应提出异议。

完整流程： references/code-review-reception.md

请求审查

时机： 每项任务完成后、主要功能完成后、合并前

流程：

1. 先排查边界情况（见下文）
2. 获取 SHA：BASE_SHA=$(git rev-parse HEAD~1) 和 HEAD_SHA=$(git rev-parse HEAD)
3. 向 code-reviewer 子 Agent 分派以下内容：WHAT、PLAN、BASE_SHA、HEAD_SHA、DESCRIPTION
4. 立即修复 Critical 问题；继续之前修复 Important 问题

完整流程： references/requesting-code-review.md

边界情况排查

时机： 实现完成后、请求 code-reviewer 之前

流程：

1. 使用侧重边界情况的提示词调用 /ck:scout
2. Scout 分析：受影响的文件、数据流、错误路径、边界条件
3. 检查 scout 的发现，找出潜在问题
4. 在代码审查前解决关键缺口

完整流程： references/edge-case-scouting.md

任务管理的审查流水线

时机： 多文件功能（更改的文件数为 3 个或以上）、并行 code-reviewer 审查范围、包含 Critical 修复迭代的审查周期。

备用方案： 任务工具（TaskCreate/TaskUpdate/TaskGet/TaskList）仅限 CLI 使用，在 VSCode 扩展中不可用。如果调用报错，请使用 TodoWrite 进行跟踪，并按顺序运行流水线。审查质量不变。

流水线： scout → review → adversarial → fix → verify（每个环节都是具有依赖链的 Task）

TaskCreate: "Scout edge cases"         → pending
TaskCreate: "Review implementation"    → pending, blockedBy: [scout]
TaskCreate: "Adversarial review"       → pending, blockedBy: [review]
TaskCreate: "Fix critical issues"      → pending, blockedBy: [adversarial]
TaskCreate: "Verify fixes pass"        → pending, blockedBy: [fix]

并行审查： 为相互独立的文件组（例如后端和前端）启动范围明确的 code-reviewer 子 Agent。所有审查员完成后，修复任务才会解除阻塞。

重新审查周期： 如果修复引入了新问题，则创建第 2 轮审查任务。最多进行 3 轮，之后升级给用户处理。

完整流程： references/task-management-reviews.md

验证关卡

铁律： 没有最新的验证证据，绝不声称任务已完成

关卡： 确定命令 → 完整运行 → 阅读输出 → 验证确认 → 然后再声明

要求：

• 测试通过：输出显示失败数为 0
• 构建成功：退出码为 0
• Bug 已修复：原始症状通过验证
• 满足要求：已核对清单

危险信号： 使用“应该”“可能”“看起来像”等表述、验证前就满意、轻信 Agent 的报告

完整流程： references/verification-before-completion.md

与工作流集成

• Subagent 驱动： Scout → Review → Adversarial → 验证后再开始下一项任务
• 拉取请求： Scout → 代码质量 → Adversarial → 合并
• 任务流水线： 创建有依赖关系的审查任务 → 沿链自动解除阻塞
• Cook 交接： Cook 完成阶段 → 执行审查流水线任务（包括 adversarial）→ 全部完成 → Cook 继续
• PR 审查： /code-review #123 → 获取差异 → 对 PR 更改进行完整的 3 阶段审查
• 提交审查： /code-review abc1234 → 使用完整流水线审查指定提交

代码库分析子命令

子命令	参考文档	用途
/ck:code-review codebase	references/codebase-scan-workflow.md	扫描并分析代码库
/ck:code-review codebase parallel	references/parallel-review-workflow.md	深入思考边界情况，然后并行验证

核心要点

1. 先确定输入模式——明确审查内容
2. 技术严谨性优先于社交表现
3. 审查前排查边界情况
4. 每次审查都要进行对抗性审查——无一例外
5. 先有证据，再做声明

验证。排查。红队审查。质疑。然后实现。提供证据。然后声明。