dev-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese/dev-review - Code Review
/dev-review - 代码评审
Skill Awareness: Seefor all available skills.skills/_registry.md
- Before: After
implementation/dev-coding- If issues: Fix with
, then review again/dev-coding- If major changes: Create CR via
/debrief
Review code changes for quality, security, and adherence to standards.
技能说明:请查看了解所有可用技能。skills/_registry.md
- 前置操作:在
完成实现后执行/dev-coding- 若发现问题:使用
修复后,重新进行评审/dev-coding- 若需重大变更:通过
创建变更请求(CR)/debrief
针对代码变更进行质量、安全性和标准合规性评审。
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:
- Git diff - Uncommitted or staged changes
- File list - Specific files to review
- UC reference - Files changed for a use case (from spec)
评审可基于以下内容:
- Git diff - 未提交或已暂存的变更
- 文件列表 - 指定要评审的文件
- UC编号 - 对应用例的变更文件(来自需求规范)
Output
输出格式
markdown
undefinedmarkdown
undefinedReview 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
- [安全] 存在SQL注入风险
src/api/users.ts:45 - [Bug] 存在空指针问题
src/utils/parse.ts:23
🟡 Important (should fix)
🟡 重要(建议修复)
- [performance] N+1 query in
src/api/posts.ts:67 - [error-handling] Unhandled promise rejection
- [性能] 存在N+1查询问题
src/api/posts.ts:67 - [错误处理] 存在未捕获的Promise拒绝
🔵 Suggestions (nice to have)
🔵 建议(可选优化)
- [style] Consider extracting to helper function
- [naming] is too generic, suggest
datauserProfile
- [风格] 建议提取为辅助函数
- [命名] 过于通用,建议改为
datauserProfile
By File
按文件统计
- - 2 issues
src/api/auth.ts - - 1 suggestion
src/components/Form.tsx
- - 2个问题
src/api/auth.ts - - 1条建议
src/components/Form.tsx
Positives
亮点
- Good error handling in login flow
- Clean separation of concerns
undefined- 登录流程的错误处理完善
- 关注点分离清晰
undefinedWorkflow
工作流程
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.md1. 获取待评审的变更
→ git diff(未提交变更)
→ git diff --staged(仅已暂存变更)
→ 读取指定文件
2. 查阅项目规范
→ plans/scout/README.md(规范章节)
→ CLAUDE.md
→ .eslintrc, tsconfig.json
3. 查阅相关需求规范(若提供UC编号)
→ plans/features/{feature}/specs/{UC}/README.mdPhase 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
undefinedmarkdown
undefinedSecurity 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
undefinedmarkdown
undefinedQuality 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
undefinedmarkdown
undefinedConvention 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?
undefinedPhase 6: Spec Compliance (if UC provided)
阶段6:规范合规性检查(若提供UC编号)
markdown
undefinedmarkdown
undefinedSpec 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- 新增了“记住我”复选框(是否已获批?)
undefinedPhase 7: Generate Review
阶段7:生成评审报告
Compile findings into review output format.
Severity Levels:
| Level | Icon | Meaning | Action |
|---|---|---|---|
| Critical | 🔴 | Security risk, bug, breaks functionality | Must fix before merge |
| Important | 🟡 | Performance, maintainability issues | Should fix |
| Suggestion | 🔵 | Style, improvements | Nice to have |
| Positive | ✅ | Good practice noted | Encouragement |
Review Verdicts:
| Verdict | When |
|---|---|
| ✅ Approve | No critical/important issues |
| ⚠️ Request Changes | Has critical or multiple important issues |
| ❓ Needs Discussion | Unclear 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
undefinedmarkdown
undefinedPositives
亮点
- Clean separation of API and business logic
- Good error messages for users
- Comprehensive input validation
undefined- API与业务逻辑分离清晰
- 给用户的错误提示友好
- 输入验证全面
undefinedTools Used
使用工具
| Tool | Purpose |
|---|---|
| git diff, git log |
| Read changed files |
| Search for patterns |
| Find related files |
| 工具 | 用途 |
|---|---|
| git diff、git log |
| 读取变更文件 |
| 搜索模式匹配 |
| 查找相关文件 |
Integration
技能集成
| Skill | Relationship |
|---|---|
| Review after implementation |
| Get project conventions |
| Check spec compliance |
| 技能 | 关系 |
|---|---|
| 实现完成后进行评审 |
| 获取项目规范 |
| 检查规范合规性 |
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] Promise rejection not handled. If API fails, user sees nothing.
src/components/LoginForm.tsx:34tsx// Add error state .catch(err => setError(err.message))
- [错误处理] Promise拒绝未处理。若API调用失败,用户将看不到任何提示。
src/components/LoginForm.tsx:34tsx// 添加错误状态 .catch(err => setError(err.message))
🔵 Suggestions
🔵 建议
- [naming]
src/lib/api.ts:12is generic. Considerdatafor clarity.credentials
- [命名]
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