dev-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/dev-review - Code Review

/dev-review - 代码评审

Skill Awareness: See
skills/_registry.md
for all available skills.
  • Before: After
    /dev-coding
    implementation
  • If issues: Fix with
    /dev-coding
    , then review again
  • If major changes: Create CR via
    /debrief
Review code changes for quality, security, and adherence to standards.
技能说明:请查看
skills/_registry.md
了解所有可用技能。
  • 前置操作:在
    /dev-coding
    完成实现后执行
  • 若发现问题:使用
    /dev-coding
    修复后,重新进行评审
  • 若需重大变更:通过
    /debrief
    创建变更请求(CR)
针对代码变更进行质量、安全性和标准合规性评审。

When to Use

适用场景

  • After implementing a feature
  • Before merging a PR
  • To get feedback on approach
  • To catch issues before production
  • 功能实现完成后
  • 合并PR之前
  • 寻求方案反馈时
  • 上线前排查问题

Usage

使用方法

/dev-review                      # Review uncommitted changes
/dev-review --staged             # Review staged changes only
/dev-review src/auth/            # Review specific directory
/dev-review UC-AUTH-001          # Review changes for specific UC
/dev-review                      # 评审未提交的变更
/dev-review --staged             # 仅评审已暂存的变更
/dev-review src/auth/            # 评审指定目录
/dev-review UC-AUTH-001          # 评审特定用例(UC)的变更

Input

输入来源

Reviews can be based on:
  1. Git diff - Uncommitted or staged changes
  2. File list - Specific files to review
  3. UC reference - Files changed for a use case (from spec)
评审可基于以下内容:
  1. Git diff - 未提交或已暂存的变更
  2. 文件列表 - 指定要评审的文件
  3. UC编号 - 对应用例的变更文件(来自需求规范)

Output

输出格式

markdown
undefined
markdown
undefined

Review Summary

评审总结

Verdict: ✅ Approve | ⚠️ Request Changes | ❓ Needs Discussion
Stats: X files, Y additions, Z deletions
结论:✅ 批准 | ⚠️ 请求修改 | ❓ 需要讨论
统计:X个文件,Y行新增,Z行删除

Issues Found

发现的问题

🔴 Critical (must fix)

🔴 严重(必须修复)

  • [security] SQL injection risk in
    src/api/users.ts:45
  • [bug] Null pointer in
    src/utils/parse.ts:23
  • [安全]
    src/api/users.ts:45
    存在SQL注入风险
  • [Bug]
    src/utils/parse.ts:23
    存在空指针问题

🟡 Important (should fix)

🟡 重要(建议修复)

  • [performance] N+1 query in
    src/api/posts.ts:67
  • [error-handling] Unhandled promise rejection
  • [性能]
    src/api/posts.ts:67
    存在N+1查询问题
  • [错误处理] 存在未捕获的Promise拒绝

🔵 Suggestions (nice to have)

🔵 建议(可选优化)

  • [style] Consider extracting to helper function
  • [naming]
    data
    is too generic, suggest
    userProfile
  • [风格] 建议提取为辅助函数
  • [命名]
    data
    过于通用,建议改为
    userProfile

By File

按文件统计

  • src/api/auth.ts
    - 2 issues
  • src/components/Form.tsx
    - 1 suggestion
  • src/api/auth.ts
    - 2个问题
  • src/components/Form.tsx
    - 1条建议

Positives

亮点

  • Good error handling in login flow
  • Clean separation of concerns
undefined
  • 登录流程的错误处理完善
  • 关注点分离清晰
undefined

Workflow

工作流程

Phase 1: Gather Context

阶段1:收集上下文

1. Get changes to review
   → git diff (uncommitted)
   → git diff --staged (staged only)
   → Read specific files

2. Read project conventions
   → plans/scout/README.md (Conventions section)
   → CLAUDE.md
   → .eslintrc, tsconfig.json

3. Read related spec (if UC provided)
   → plans/features/{feature}/specs/{UC}/README.md
1. 获取待评审的变更
   → git diff(未提交变更)
   → git diff --staged(仅已暂存变更)
   → 读取指定文件

2. 查阅项目规范
   → plans/scout/README.md(规范章节)
   → CLAUDE.md
   → .eslintrc, tsconfig.json

3. 查阅相关需求规范(若提供UC编号)
   → plans/features/{feature}/specs/{UC}/README.md

Phase 2: Analyze Changes

阶段2:分析变更

For each changed file:
1. Understand the change
   - What was added/modified/removed?
   - What is the intent?

2. Check against spec (if available)
   - Does implementation match spec?
   - Any missing requirements?

3. Run through checklists
   - Security
   - Performance
   - Error handling
   - Style/conventions
   - Testing
针对每个变更文件:
1. 理解变更内容
   - 新增/修改/删除了什么?
   - 变更的意图是什么?

2. 对照需求规范检查(若有)
   - 实现是否符合规范?
   - 是否有遗漏的需求?

3. 逐项检查清单
   - 安全性
   - 性能
   - 错误处理
   - 风格/规范
   - 测试

Phase 3: Security Review

阶段3:安全评审

markdown
undefined
markdown
undefined

Security Checklist

安全检查清单

[ ] Input Validation - User input sanitized? - SQL/NoSQL injection prevented? - XSS prevented (HTML escaped)?
[ ] Authentication - Auth required where needed? - Token validated correctly? - Session handled securely?
[ ] Authorization - Permissions checked? - Can't access others' data? - Admin functions protected?
[ ] Data Protection - Passwords hashed? - Sensitive data not logged? - No secrets in code?
[ ] API Security - Rate limiting present? - CORS configured? - No sensitive data in URLs?

**Common Security Issues:**

```typescript
// BAD: SQL injection
const query = `SELECT * FROM users WHERE id = ${userId}`;

// GOOD: Parameterized
const query = `SELECT * FROM users WHERE id = $1`;
await db.query(query, [userId]);

// BAD: XSS vulnerable
element.innerHTML = userInput;

// GOOD: Escaped
element.textContent = userInput;

// BAD: Hardcoded secret
const apiKey = "sk-1234567890";

// GOOD: Environment variable
const apiKey = process.env.API_KEY;
[ ] 输入验证 - 用户输入是否经过清理? - 是否防范了SQL/NoSQL注入? - 是否防范了XSS攻击(HTML转义)?
[ ] 身份认证 - 必要场景是否要求认证? - Token验证是否正确? - Session处理是否安全?
[ ] 权限控制 - 是否检查了权限? - 是否无法访问他人数据? - 管理员功能是否受保护?
[ ] 数据保护 - 密码是否加密存储? - 敏感数据是否未被日志记录? - 代码中是否存在硬编码密钥?
[ ] API安全 - 是否存在速率限制? - CORS配置是否正确? - URL中是否包含敏感数据?

**常见安全问题:**

```typescript
// 不安全:SQL注入
const query = `SELECT * FROM users WHERE id = ${userId}`;

// 安全:参数化查询
const query = `SELECT * FROM users WHERE id = $1`;
await db.query(query, [userId]);

// 不安全:存在XSS风险
element.innerHTML = userInput;

// 安全:转义处理
element.textContent = userInput;

// 不安全:硬编码密钥
const apiKey = "sk-1234567890";

// 安全:使用环境变量
const apiKey = process.env.API_KEY;

Phase 4: Quality Review

阶段4:质量评审

markdown
undefined
markdown
undefined

Quality Checklist

质量检查清单

[ ] Error Handling - Errors caught and handled? - User-friendly error messages? - Errors logged for debugging? - No swallowed errors?
[ ] Performance - No N+1 queries? - Large lists paginated? - Heavy operations async? - No memory leaks?
[ ] Maintainability - Code readable? - Functions not too long? - No magic numbers/strings? - DRY (no unnecessary duplication)?
[ ] Testing - New code has tests? - Edge cases covered? - Tests actually test something?

**Common Quality Issues:**

```typescript
// BAD: N+1 query
const posts = await getPosts();
for (const post of posts) {
  post.author = await getUser(post.authorId); // Query per post!
}

// GOOD: Batch query
const posts = await getPosts({ include: { author: true } });

// BAD: Swallowed error
try {
  await doSomething();
} catch (e) {
  // Nothing - error disappears!
}

// GOOD: Handle or rethrow
try {
  await doSomething();
} catch (e) {
  logger.error('Failed to do something', e);
  throw new AppError('Operation failed', e);
}

// BAD: Magic number
if (retries > 3) { ... }

// GOOD: Named constant
const MAX_RETRIES = 3;
if (retries > MAX_RETRIES) { ... }
[ ] 错误处理 - 错误是否被捕获并处理? - 是否有友好的用户错误提示? - 错误是否被记录用于调试? - 是否存在被吞掉的错误?
[ ] 性能 - 是否存在N+1查询? - 大型列表是否分页? - 重操作是否异步执行? - 是否存在内存泄漏?
[ ] 可维护性 - 代码是否易读? - 函数是否过长? - 是否存在魔法数字/字符串? - 是否遵循DRY原则(无不必要重复)?
[ ] 测试 - 新代码是否有测试用例? - 是否覆盖了边缘场景? - 测试用例是否有效?

**常见质量问题:**

```typescript
// 不好:N+1查询
const posts = await getPosts();
for (const post of posts) {
  post.author = await getUser(post.authorId); // 每个帖子都发起查询!
}

// 好:批量查询
const posts = await getPosts({ include: { author: true } });

// 不好:错误被吞掉
try {
  await doSomething();
} catch (e) {
  // 无处理 - 消息丢失!
}

// 好:处理或重新抛出
try {
  await doSomething();
} catch (e) {
  logger.error('操作失败', e);
  throw new AppError('操作失败', e);
}

// 不好:魔法数字
if (retries > 3) { ... }

// 好:命名常量
const MAX_RETRIES = 3;
if (retries > MAX_RETRIES) { ... }

Phase 5: Convention Review

阶段5:规范评审

markdown
undefined
markdown
undefined

Convention Checklist (from scout)

规范检查清单(来自scout)

[ ] Naming - Variables: {convention from scout} - Files: {convention from scout} - Components: {convention from scout}
[ ] Structure - File in correct location? - Follows project patterns? - Imports organized?
[ ] Style - Matches .prettierrc / .eslintrc? - Consistent with codebase? - No linting errors?
[ ] Git - Commit message format correct? - No unrelated changes? - No debug code / console.log?
undefined
[ ] 命名 - 变量:{遵循scout中的规范} - 文件:{遵循scout中的规范} - 组件:{遵循scout中的规范}
[ ] 结构 - 文件是否在正确位置? - 是否遵循项目模式? - 导入是否有序?
[ ] 风格 - 是否匹配.prettierrc / .eslintrc? - 是否与代码库保持一致? - 是否存在lint错误?
[ ] Git - 提交信息格式是否正确? - 是否存在无关变更? - 是否存在调试代码/console.log?
undefined

Phase 6: Spec Compliance (if UC provided)

阶段6:规范合规性检查(若提供UC编号)

markdown
undefined
markdown
undefined

Spec Compliance

规范合规性

Requirements Met

已满足需求

  • Login endpoint created
  • Returns token on success
  • Returns error on invalid credentials
  • 已创建登录端点
  • 成功时返回Token
  • 凭证无效时返回错误

Requirements Not Met

未满足需求

  • Rate limiting not implemented (spec said 5 attempts/min)
  • 未实现速率限制(规范要求5次/分钟)

Not in Spec

超出规范内容

  • Added "remember me" checkbox (is this approved?)
undefined
  • 新增了“记住我”复选框(是否已获批?)
undefined

Phase 7: Generate Review

阶段7:生成评审报告

Compile findings into review output format.
Severity Levels:
LevelIconMeaningAction
Critical🔴Security risk, bug, breaks functionalityMust fix before merge
Important🟡Performance, maintainability issuesShould fix
Suggestion🔵Style, improvementsNice to have
PositiveGood practice notedEncouragement
Review Verdicts:
VerdictWhen
✅ ApproveNo critical/important issues
⚠️ Request ChangesHas critical or multiple important issues
❓ Needs DiscussionUnclear requirements, architectural concerns
将发现的问题整理为指定的评审输出格式。
严重等级说明:
等级图标含义处理方式
严重🔴安全风险、Bug、功能故障合并前必须修复
重要🟡性能、可维护性问题建议修复
建议🔵风格、优化建议可选优化
亮点值得肯定的实践鼓励继续保持
评审结论说明:
结论适用场景
✅ 批准无严重/重要问题
⚠️ 请求修改存在严重问题或多个重要问题
❓ 需要讨论需求不明确、架构存在疑问

Review Best Practices

评审最佳实践

Be Constructive

保持建设性

markdown
// BAD
"This code is bad"

// GOOD
"This could cause a SQL injection. Consider using parameterized queries:
```sql
SELECT * FROM users WHERE id = $1
```"
markdown
// 不好
"这段代码很差"

// 好
"这段代码存在SQL注入风险,建议使用参数化查询:
```sql
SELECT * FROM users WHERE id = $1
```"

Explain Why

说明原因

markdown
// BAD
"Don't use var"

// GOOD
"Use const/let instead of var - var has function scope which can lead to
unexpected behavior. const also signals intent that the value won't change."
markdown
// 不好
"不要使用var"

// 好
"建议使用const/let替代var - var是函数作用域,可能导致意外行为。const还能明确表示值不会被修改的意图。"

Suggest Alternatives

提供替代方案

markdown
// Issue + Solution
"The N+1 query here will cause performance issues with many posts.

Consider using an include/join:
```typescript
const posts = await db.posts.findMany({
  include: { author: true }
});
```"
markdown
// 问题+解决方案
"此处的N+1查询会在帖子数量较多时导致性能问题。

建议使用关联查询:
```typescript
const posts = await db.posts.findMany({
  include: { author: true }
});
```"

Acknowledge Good Work

肯定优秀实践

markdown
undefined
markdown
undefined

Positives

亮点

  • Clean separation of API and business logic
  • Good error messages for users
  • Comprehensive input validation
undefined
  • API与业务逻辑分离清晰
  • 给用户的错误提示友好
  • 输入验证全面
undefined

Tools Used

使用工具

ToolPurpose
Bash
git diff, git log
Read
Read changed files
Grep
Search for patterns
Glob
Find related files
工具用途
Bash
git diff、git log
Read
读取变更文件
Grep
搜索模式匹配
Glob
查找相关文件

Integration

技能集成

SkillRelationship
/dev-coding
Review after implementation
/dev-scout
Get project conventions
/dev-specs
Check spec compliance
技能关系
/dev-coding
实现完成后进行评审
/dev-scout
获取项目规范
/dev-specs
检查规范合规性

Example Review

评审示例

User: /dev-review UC-AUTH-001

Phase 1: Gather
- Get git diff for UC-AUTH-001 files
- Read scout conventions
- Read UC-AUTH-001 spec

Phase 2-6: Analyze
- src/api/auth/login.ts: Clean ✓
- src/components/LoginForm.tsx: 1 issue
- src/lib/api.ts: 1 suggestion

Phase 7: Output
用户:/dev-review UC-AUTH-001

阶段1:收集
- 获取UC-AUTH-001相关文件的git diff
- 查阅scout规范
- 查阅UC-AUTH-001需求规范

阶段2-6:分析
- src/api/auth/login.ts: 代码规范 ✓
- src/components/LoginForm.tsx: 1个问题
- src/lib/api.ts: 1条建议

阶段7:输出

Review Summary

评审总结

Verdict: ⚠️ Request Changes
Stats: 3 files, +245 additions, -12 deletions
结论:⚠️ 请求修改
统计:3个文件,+245行新增,-12行删除

Issues Found

发现的问题

🔴 Critical

🔴 严重

None

🟡 Important

🟡 重要

  • [error-handling]
    src/components/LoginForm.tsx:34
    Promise rejection not handled. If API fails, user sees nothing.
    tsx
    // Add error state
    .catch(err => setError(err.message))
  • [错误处理]
    src/components/LoginForm.tsx:34
    Promise拒绝未处理。若API调用失败,用户将看不到任何提示。
    tsx
    // 添加错误状态
    .catch(err => setError(err.message))

🔵 Suggestions

🔵 建议

  • [naming]
    src/lib/api.ts:12
    data
    is generic. Consider
    credentials
    for clarity.
  • [命名]
    src/lib/api.ts:12
    data
    过于通用,建议改为
    credentials
    以明确含义。

Spec Compliance

规范合规性

  • POST /api/auth/login works
  • Returns token
  • Validates input
  • Missing: Rate limiting (spec requirement)
  • POST /api/auth/login功能正常
  • 返回Token
  • 输入验证有效
  • 缺失:速率限制(规范要求)

Positives

亮点

  • Good validation on both client and server
  • Clean component structure
  • Proper TypeScript types
undefined
  • 客户端和服务端均有完善的输入验证
  • 组件结构清晰
  • TypeScript类型定义规范
undefined