# Rpiv Loop:code Review

> 在提交前运行的技术代码审查，用于质量和错误检查

- Skill: `zhuqingxun/rpiv-loop-code-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zhuqingxun/rpiv-loop-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhuqingxun/rpiv-loop-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhuqingxun (https://skillmd.com/u/zhuqingxun)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhuqingxun/rpiv-loop-code-review

---


对最近更改的文件执行技术代码审查。

> **skill 产物引导**：若本次 `git diff` 的主体是 `SKILL.md`、`references/**.md` 等技能定义文件（而非可执行代码），或本次特性 PRD 的 frontmatter `product_types` 含 `skill`，则本技能下方的审查维度（SQL 注入 / N+1 查询 / 类型提示等）对其基本不适用——**改用 `/rpiv-loop:code-audit <skill 目标>`**，它支持 skill 作为审计对象，且对 skill 目标会自动追加 portability（可迁移性）维度。混合产物（diff 同时含 `.py` 等代码文件）时，代码部分仍按本技能正常审查。

## 核心原则

审查理念：

- 简单是终极的复杂 - 每一行都应该证明其存在的价值
- 代码被阅读的次数远多于编写 - 优化可读性
- 最好的代码往往是你没有写的代码
- 优雅源于意图的清晰和表达的简洁

## 审查内容

首先收集代码库上下文以了解代码库标准和模式。

首先检查：

- CLAUDE.md
- README.md
- /core 模块中的关键文件
- /docs 目录中记录的标准

在充分理解后

运行这些命令：

```bash
git status
git diff HEAD
git diff --stat HEAD
```

然后检查新文件列表：

```bash
git ls-files --others --exclude-standard
```

完整阅读每个新文件。完整阅读每个更改的文件（不仅仅是 diff）以理解完整上下文。

对于每个更改的文件或新文件，分析：

1. **逻辑错误**
   - 差一错误
   - 不正确的条件判断
   - 缺少错误处理
   - 竞争条件

2. **安全问题**
   - SQL 注入漏洞
   - XSS 漏洞
   - 不安全的数据处理
   - 暴露的密钥或 API 密钥

3. **性能问题**
   - N+1 查询
   - 低效的算法
   - 内存泄漏
   - 不必要的计算

4. **代码质量**
   - 违反 DRY 原则
   - 过于复杂的函数
   - 命名不当
   - 缺少类型提示/注解

5. **遵守代码库标准和现有模式**
   - 遵守 /docs 目录中记录的标准
   - 代码检查、类型和格式标准
   - 日志记录标准
   - 测试标准

6. **删测试资产覆盖核对**（当 diff 含测试文件/测试资产删除时强制）
   - 对每个被删测试，**逐条**列出其断言维度（文本内容 / 几何 / fill / 字号 / 边界 等），不能只看测试名或参数化的 `visual_type` 名
   - 对每个断言维度，核对是否真有替代测试覆盖——**参数化覆盖同名 type ≠ 覆盖该测试所有断言维度**
   - 任一断言维度无替代覆盖 → 标记为问题，要求"先补再删"，缺口补齐前不得删除

## 验证问题是否真实

- 为发现的问题运行特定测试
- 确认类型错误是合法的
- 结合上下文验证安全问题

## 输出格式

将新文件保存到 `rpiv/validation/code-review-{kebab-case-feature-name}.md`

- 如果 `rpiv/validation/` 目录不存在则创建

### 文件格式

文件必须包含 YAML frontmatter 和内容：

```markdown
---
description: "代码审查报告: {feature-name}"
status: pending
created_at: {YYYY-MM-DDTHH:MM:SS}
updated_at: {YYYY-MM-DDTHH:MM:SS}
archived_at: null
---

# 代码审查报告

{审查内容}
```

**Frontmatter 字段说明：**
- `description`: 文件描述
- `status`: 文件状态，新创建时固定为 `pending`
- `created_at`: 创建时间戳，ISO 8601 格式
- `updated_at`: 更新时间戳，创建时与 created_at 相同
- `archived_at`: 归档时间戳，创建时固定为 `null`

**统计：**

- 修改的文件：0
- 添加的文件：0
- 删除的文件：0
- 新增行：0
- 删除行：0

**对于每个发现的问题：**

```
severity: critical|high|medium|low
status: open
file: path/to/file.py
line: 42
issue: [一行描述]
detail: [解释为什么这是问题]
suggestion: [如何修复]
```

> `status` 字段取值：`open`（新建时固定）、`fixed`（已修复）、`wont_fix`（评估后决定不修复，下方附 `wont_fix_reason`）、`deferred`（延后跟踪，下方附 `deferred_reason`，并在 `rpiv/todo/` 创建对应待办文件）。由 code-review-fix 流程在修复完成后回写，禁止使用无归属的 `skipped` 状态（见 code-review-fix SKILL step 2）。

如果未发现问题："代码审查通过。未检测到技术问题。"

## 完成后续

审查产出后，按结论闭合**本审查文件**的 frontmatter `status`（填补干净审查的状态闭合路径——干净审查不会触发 `code-review-fix`，必须由本技能自闭合，否则文件永久卡在 `pending`）：

- **干净通过**（输出"代码审查通过。未检测到技术问题。"，或仅余 low / by-design 等**无需 `code-review-fix` 介入**的观察）：不会有后续修复流程被触发，**由本技能直接闭合**——将审查文件 `status` 改为 `completed`，同步 `updated_at`。
- **发现需修复的问题**（存在 `status: open` 的 critical / high / medium）：保持 `status: pending`，提示用户运行 `/rpiv-loop:code-review-fix <审查文件路径>`，由该流程修复后翻 `completed`（见 code-review-fix SKILL step 4 闭环校验）。

> 单一职责说明：两条路径**互斥**（一次审查要么干净、要么有问题），不会双写 status，与 `references/frontmatter-spec.md` 职责表 code-review 行一致。

## 重要提示

- 要具体（行号，不要模糊的抱怨）
- 报告**所有**发现的问题，包括不确定的和低严重度的——用 severity 分级供下游 code-review-fix 过滤；宁可上报后被降级，不可自行压下不报。纯风格 / 命名偏好类 nit 不属于问题范围
- 建议修复方法，不要只是抱怨
- 将安全问题标记为 CRITICAL