---
name: code-review
description: 收集工作区未提交改动或最近一次提交的 git 变更面，做只读代码审查并给出带文件行号的问题清单。适用：审查改动、检查刚写的代码质量。不修改代码。
user-invocable: true
argument-hint: "[可选：审查焦点]"
---

# 代码审查

你正在执行 **code-review** 技能：对当前 git 变更面做只读审查，产出带证据的审查报告。

## 上下文

- 工作区：<%= workspacePath %>
- 用户请求：${arguments}

## 目标与完成标准

- **目标**：基于真实 diff 与相邻代码，审查正确性、边界、范围、架构、契约、安全与测试覆盖。
- **完成标准**：报告已写入工作区；消息流给出自然语言总结（结论、问题清单、优点、未能验证项）。除本技能约定的报告文件外，**不修改**业务代码、配置与其它文件。

## 阶段语义

### 1. 确定审查范围（git 事实）

先确认当前目录是 git 仓库。优先收集**工作区未提交改动**；工作区干净则回退到**最近一次提交**。

建议只读命令（按需组合）：

- `git rev-parse --is-inside-work-tree`
- `git status --porcelain`（识别未跟踪新文件）
- `git diff --name-only HEAD` / `git diff --stat HEAD` / `git diff --unified=3 HEAD`
- 工作区干净时：对 `HEAD~1 HEAD` 做同样的 diff

若不是 git 仓库，或既无未提交改动也无可比较提交，向用户说明原因并停止，不要臆造范围。

diff 过长时截取概览并标注已截断，再用只读工具补读完整文件。未跟踪文件不在 diff 中，须自行 `read`。

### 2. 只读审查

先读项目规则（`AGENTS.md` 及目录级规则）和被改动文件的相邻代码，再以真实代码为证据审查。

审查维度：

- **正确性**与失败路径
- **边界**与空值/并发等边缘情况
- **范围**是否超出用户意图
- **架构**与依赖方向
- **契约**与类型一致性
- **安全**（注入、密钥、权限）
- **测试**是否覆盖新行为

约束：

- 只读：不 `edit` / `write` 业务文件，不执行会改状态的命令，不向用户提问（范围不清时在报告的「未能验证」中说明）。
- 无法验证的点写入未能验证项，不要臆断。
- 每个问题尽量指出文件与行号，并给出可执行的修改建议。

需要并行加深某个子系统时，可同一轮发多个只读 `task`；是否并行由你判断。

### 3. 组织报告

报告须包含：

| 字段 | 含义 |
|------|------|
| `verdict` | `pass` / `conditional` / `block` |
| `summary` | 一句话总评 |
| `findings` | 问题列表：severity（critical/high/medium/low/nit）、file、line、summary、suggestion |
| `strengths` | 做得好的地方 |
| `unverified` | 未能验证、需人工确认的点 |

判定规则（必须遵守）：

- 存在 **critical** 问题 → `verdict` 必须为 `block`，即使主观想给 pass。
- 声称 `pass` 但存在 **high** 问题 → 降为 `conditional`。

## 产物落盘

1. 将完整审查报告写入 `<%= workspacePath %>/.nova/reports/`（目录不存在则创建），例如 `code-review-<日期或主题>.md`。
2. 报告用 markdown：结论、范围说明、问题清单（含严重度与位置）、优点、未能验证项。
3. 在消息流用自然语言总结，并给出文件路径；不要把原始 JSON/状态码甩给用户。

## 约束

- 审查过程只读；唯一允许的写入是本技能的报告文件。
- 不要调用 `start_workflow`；本能力已是 skill，用 `invoke_skill` 或 `/code-review` 进入即可。
- 回复使用用户语言（默认简体中文）。