code-review

资源

scripts/
  validate-code-review.sh
references/
  review-patterns.md

代码审查质量技能

此技能将教你如何使用 GoodVibes 精准工具进行全面、符合企业级标准的代码审查。系统化的代码审查可以及早发现问题、确保一致性、验证安全性和性能，并维持整个代码库的高质量标准。

何时使用此技能

在以下情况下加载此技能：

• 审查拉取请求或合并请求
• 执行代码质量审计
• 验证实现的安全性和性能
• 检查是否遵循架构模式
• 评估测试覆盖率和质量
• 评估无障碍合规性
• 向开发者提供结构化反馈

触发短语：“审查这段代码”、“检查 PR”、“质量审计”、“安全审查”、“性能审查”、“验证实现”。

核心工作流

阶段 1：发现——了解变更

审查之前，先了解变更内容、原因和影响范围。

步骤 1.1：收集变更背景

使用 discover 映射所有变更文件，并确定变更类型。

discover:
  queries:
    - id: changed_files
      type: glob
      patterns: ["src/**/*"]  # List changed files for review
    - id: new_files
      type: glob
      patterns: ["**/*"]
    - id: test_files
      type: glob
      patterns: ["**/*.test.ts", "**/*.test.tsx", "**/*.spec.ts", "**/*.spec.tsx"]
  verbosity: files_only

从 git 中提取：

precision_exec:
  commands:
    - cmd: "git diff --name-only HEAD~1..HEAD"
  verbosity: minimal

可以了解：

• 变更集中修改的所有文件
• 新增、修改和删除的文件
• 是否包含测试文件（或缺少测试文件）
• 变更范围（前端、后端、全栈）

步骤 1.2：分析变更代码

使用 precision_read 检查实际变更。

precision_read:
  files:
    - path: "src/api/user-routes.ts"  # Example changed file
      extract: content
    - path: "src/components/UserProfile.tsx"
      extract: content
  output:
    max_per_item: 200
  verbosity: standard

获取差异上下文：

precision_exec:
  commands:
    - cmd: "git diff HEAD~1..HEAD -- src/api/user-routes.ts"
  verbosity: standard

步骤 1.3：查找相关代码

使用 discover 查找变更符号的导入、导出和使用位置。

discover:
  queries:
    - id: function_exports
      type: grep
      pattern: "export (function|const|class) (createUser|updateUser|deleteUser)"
      glob: "**/*.{ts,tsx,js,jsx}"
    - id: usage_sites
      type: grep
      pattern: "(createUser|updateUser|deleteUser)\\("
      glob: "**/*.{ts,tsx,js,jsx}"
    - id: related_tests
      type: grep
      pattern: "(createUser|updateUser|deleteUser)"
      glob: "**/*.test.{ts,tsx}"
  verbosity: locations

可以了解：

• 变更的函数在哪里使用
• 潜在的破坏性变更
• 变更代码的测试覆盖情况
• 在整个代码库中的连锁影响

阶段 2：安全审查

安全问题至关重要，必须在审查中发现。

步骤 2.1：检查常见漏洞

使用 discover 查找安全反模式。

discover:
  queries:
    # SQL Injection
    - id: sql_injection
      type: grep
      pattern: '(query|execute|sql).*[`$].*\$\{'
      glob: "**/*.{ts,tsx,js,jsx}"
    # XSS vulnerabilities
    - id: dangerous_html
      type: grep
      pattern: "(dangerouslySetInnerHTML|innerHTML|outerHTML)"
      glob: "**/*.{ts,tsx,jsx}"
    # Hardcoded secrets
    - id: hardcoded_secrets
      type: grep
      pattern: '(password|secret|api[_-]?key|token)\s*=\s*["''][^"'']+["'']'
      glob: "**/*.{ts,tsx,js,jsx,json}"
    # Missing authentication
    - id: unauthed_routes
      type: grep
      pattern: "export (async )?function (GET|POST|PUT|DELETE|PATCH)"
      glob: "src/app/api/**/*.ts"
  verbosity: locations

需要检查的严重模式：

模式	严重性	影响
SQL 注入	严重	允许攻击者读取或修改数据库
XSS 漏洞	严重	允许注入脚本、劫持会话
硬编码密钥	严重	源代码中暴露凭据
缺少身份验证检查	严重	暴露受保护的资源
不安全的反序列化	严重	远程代码执行
CORS 配置错误	重要	允许未经授权的来源
密码规则薄弱	重要	导致账户被攻破
缺少输入验证	重要	数据损坏、注入攻击

步骤 2.2：验证输入处理

必须验证所有外部输入。

discover:
  queries:
    # Check for validation schemas
    - id: zod_schemas
      type: grep
      pattern: "z\\.(object|string|number|array|enum)"
      glob: "**/*.{ts,tsx}"
    # Check for direct request.json() without validation
    - id: unvalidated_input
      type: grep
      pattern: "(await request\\.json\\(\\)|req\\.body)(?!.*safeParse)"
      glob: "src/app/api/**/*.ts"
    # Check for SQL parameterization
    - id: parameterized_queries
      type: grep
      pattern: "(db\\.(query|execute)|prisma\\.|sql`)"
      glob: "**/*.{ts,js}"
  verbosity: locations

验证最佳实践：

• 所有 API 路由都使用 Zod、Joi 或同等工具验证输入
• 所有数据库查询都使用参数化查询（Prisma、预处理语句）
• 文件上传需验证内容类型和大小
• URL 和重定向需依据允许列表进行验证

步骤 2.3：检查身份验证和授权

确认受保护的资源需要身份验证。

discover:
  queries:
    # Find auth middleware usage
    - id: auth_middleware
      type: grep
      pattern: "(getServerSession|auth\\(\\)|requireAuth|withAuth)"
      glob: "src/app/api/**/*.ts"
    # Find resource ownership checks
    - id: ownership_checks
      type: grep
      pattern: "(userId|authorId|ownerId)\s*===\s*(session|user|currentUser)"
      glob: "**/*.{ts,tsx}"
    # Find RBAC checks
    - id: rbac_checks
      type: grep
      pattern: "(role|permission|can)\s*===\s*"
      glob: "**/*.{ts,tsx}"
  verbosity: locations

关键检查项：

• 受保护的 API 路由会调用身份验证中间件
• 用户只能修改自己的资源（所有权检查）
• 仅限管理员执行的操作会检查管理员角色
• JWT 使用正确的密钥进行验证
• 会轮换会话令牌，并设置过期时间

阶段 3：性能审查

性能问题会损害用户体验并限制可扩展性。

步骤 3.1：检查 N+1 查询

N+1 查询是数据库性能的头号杀手。

discover:
  queries:
    # Find loops with database calls
    - id: n_plus_one
      type: grep
      pattern: "(for|forEach|map).*await.*(prisma|db|query|find)"
      glob: "**/*.{ts,tsx,js,jsx}"
    # Find Prisma include usage
    - id: prisma_includes
      type: grep
      pattern: "(findMany|findUnique|findFirst).*include:"
      glob: "**/*.{ts,js}"
  verbosity: locations

修复方法：

• 使用 include 预加载相关记录（Prisma）
• 使用联接或 SELECT IN 批量加载
• 为 GraphQL 实现 DataLoader
• 缓存经常访问的数据

第 3.2 步：检查不必要的重新渲染

React 重新渲染问题会影响前端性能。

discover:
  queries:
    # Find inline object/array creation in JSX
    - id: inline_objects
      type: grep
      pattern: "(onClick|onChange|style)=\\{\\{|=\\{\\["
      glob: "**/*.{tsx,jsx}"
    # Find missing useMemo/useCallback
    - id: missing_memoization
      type: grep
      pattern: "(map|filter|reduce)\\("
      glob: "**/*.{tsx,jsx}"
    # Find useEffect without dependencies
    - id: missing_deps
      type: grep
      pattern: "useEffect\\([^)]+\\)\\s*$"
      glob: "**/*.{tsx,jsx}"
  verbosity: locations

常见问题：

反模式	修复方法
在 props 中使用内联对象	提取为常量或使用 useMemo
在 props 中使用内联函数	使用 useCallback 包装
大型列表没有 key	添加稳定的 key prop
useEffect 缺少依赖项	将所有使用的变量添加到依赖数组
Context 导致所有内容重新渲染	拆分 Context 或使用状态管理器

第 3.3 步：检查数据库索引

缺少索引会导致查询缓慢。

precision_read:
  files:
    - path: "prisma/schema.prisma"
      extract: content
  output:
    max_per_item: 500
  verbosity: standard

确认以下字段已建立索引：

• 外键（userId、postId 等）
• 经常用于筛选的字段（status、createdAt、published）
• WHERE 子句中使用的字段
• 多列查询所需的复合索引

第 4 阶段：代码质量审查

代码质量会影响可维护性和可靠性。

第 4.1 步：检查类型安全

TypeScript 应在编译时而非运行时捕获错误。

discover:
  queries:
    # Find any types
    - id: any_usage
      type: grep
      pattern: ":\s*any(\\s|;|,|\\))"
      glob: "**/*.{ts,tsx}"
    # Find type assertions (as)
    - id: type_assertions
      type: grep
      pattern: "as (unknown|any|string|number)"
      glob: "**/*.{ts,tsx}"
    # Find non-null assertions (!)
    - id: non_null_assertions
      type: grep
      pattern: "![.;,)\\]]"
      glob: "**/*.{ts,tsx}"
    # Find unsafe member access
    - id: unsafe_access
      type: grep
      pattern: "\\?\\."
      glob: "**/*.{ts,tsx}"
  verbosity: locations

类型安全问题：

问题	严重程度	修复方法
使用 any 类型	重大	使用合适的类型或 unknown
as any 类型断言	重大	修复根本的类型问题
! 非空断言	轻微	添加空值检查
缺少返回类型	轻微	为函数返回值显式指定类型
隐式 any 参数	重大	添加参数类型

第 4.2 步：检查错误处理

所有异步操作和 API 调用都必须处理错误。

discover:
  queries:
    # Find floating promises
    - id: floating_promises
      type: grep
      pattern: "^\\s+[a-z][a-zA-Z]*\\(.*\\);$"
      glob: "**/*.{ts,tsx,js,jsx}"
    # Find empty catch blocks
    - id: empty_catch
      type: grep
      pattern: "catch.*\\{\\s*\\}"
      glob: "**/*.{ts,tsx,js,jsx}"
    # Find console.error (should use logger)
    - id: console_error
      type: grep
      pattern: "console\\.(error|warn|log)"
      glob: "**/*.{ts,tsx,js,jsx}"
  verbosity: locations

错误处理检查清单：

• 所有 Promise 都有 .catch() 或 try/catch
• 记录错误时包含上下文（用户 ID、请求 ID）
• 面向用户的错误信息经过清理（不包含堆栈跟踪）
• API 错误返回适当的 HTTP 状态码
• 为瞬时故障设置重试逻辑

第 4.3 步：检查代码组织

文件过大、复杂度过高会使代码难以维护。

precision_exec:
  commands:
    - cmd: "find src -not -path '*/node_modules/*' -not -path '*/dist/*' -name '*.ts' -o -name '*.tsx' -print0 | xargs -0 wc -l | sort -rn | head -20"
  verbosity: standard

代码组织规则：

• 文件应少于 300 行（生成的代码除外）
• 函数应少于 50 行
• 圈复杂度应小于 10
• 最大嵌套深度：3 层
• 将辅助函数提取到单独的文件中

第 5 阶段：测试审查

测试用于验证正确性并防止回归。

第 5.1 步：检查测试覆盖率

每个修改过的文件都应有测试。

discover:
  queries:
    # Find test files
    - id: test_files
      type: glob
      patterns: ["**/*.test.{ts,tsx}", "**/*.spec.{ts,tsx}"]
    # Find files without tests
    - id: source_files
      type: glob
      patterns: ["src/**/*.{ts,tsx}"]
    # Check test imports
    - id: test_imports
      type: grep
      pattern: "from ['\"].*/(api|lib|components)/"
      glob: "**/*.test.{ts,tsx}"
  verbosity: files_only

比较源文件与测试文件：

// Pseudo-logic (implement with precision tools)
const sourceFiles = results.source_files.files;
const testFiles = results.test_files.files;
const missingTests = sourceFiles.filter(f => !testFiles.some(t => t.includes(f.replace('.ts', ''))));

第 5.2 步：检查测试质量

测试应测试行为，而不是实现方式。

discover:
  queries:
    # Find skipped tests
    - id: skipped_tests
      type: grep
      pattern: "(it\\.skip|test\\.skip|describe\\.skip)"
      glob: "**/*.test.{ts,tsx}"
    # Find focused tests (.only)
    - id: focused_tests
      type: grep
      pattern: "(it\\.only|test\\.only|describe\\.only)"
      glob: "**/*.test.{ts,tsx}"
    # Find expect assertions
    - id: assertions
      type: grep
      pattern: "expect\\("
      glob: "**/*.test.{ts,tsx}"
    # Find mock usage
    - id: mocks
      type: grep
      pattern: "(vi\\.mock|jest\\.mock|vi\\.fn)"
      glob: "**/*.test.{ts,tsx}"
  verbosity: locations

测试质量检查清单：

• 没有 .skip 或 .only（合并前应移除）
• 每个测试至少包含一个断言
• 测试名称具有描述性（“它应该……”、“当……时……则……”）
• 测试彼此隔离（不共享状态）
• 谨慎使用 Mock（优先使用真实实现）
• 测试边界情况（null、空值、大值）

第 6 阶段：架构审查

违反架构规则会造成技术债务。

第 6.1 步：检查依赖方向

依赖关系应从外层流向内层。

discover:
  queries:
    # Find domain imports in UI
    - id: ui_imports_domain
      type: grep
      pattern: "from ['\"].*/(domain|core|lib)/"
      glob: "src/components/**/*.{ts,tsx}"
    # Find UI imports in domain
    - id: domain_imports_ui
      type: grep
      pattern: "from ['\"].*/(components|pages|app)/"
      glob: "src/domain/**/*.{ts,tsx}"
    # Find circular dependencies
    - id: imports
      type: grep
      pattern: "^import.*from"
      glob: "src/**/*.{ts,tsx}"
  verbosity: locations

依赖规则：

• UI 组件可以导入 hooks、utils 和领域逻辑
• 领域逻辑不得导入 UI 组件
• API 路由可以导入领域逻辑，但不能导入 UI
• 共享 utils 应没有任何依赖

第 6.2 步：检查分层违规

discover:
  queries:
    # Database access in components
    - id: db_in_components
      type: grep
      pattern: "(prisma|db\\.(query|execute))"
      glob: "src/components/**/*.{ts,tsx}"
    # Business logic in API routes
    - id: logic_in_routes
      type: grep
      pattern: "export (async )?function (GET|POST)"
      glob: "src/app/api/**/*.ts"
  verbosity: files_only

阅读路由处理程序并检查：

• 路由处理程序应少于 30 行（将工作委托给服务）
• 组件中没有数据库查询（使用服务器操作或 API 路由）
• 路由中没有业务逻辑（提取到服务层）

第 7 阶段：无障碍审查

无障碍设计可确保所有人都能使用你的应用。

第 7.1 步：检查语义化 HTML

使用恰当的 HTML 元素来确保无障碍。

discover:
  queries:
    # Find div buttons (should be <button>)
    - id: div_buttons
      type: grep
      pattern: "<div.*(onClick|onKeyDown)"
      glob: "**/*.{tsx,jsx}"
    # Find missing alt text
    - id: missing_alt
      type: grep
      pattern: "<img(?![^>]*alt=)"
      glob: "**/*.{tsx,jsx}"
    # Find missing labels
    - id: missing_labels
      type: grep
      pattern: "<input(?![^>]*aria-label)(?![^>]*id=)"
      glob: "**/*.{tsx,jsx}"
    # Find missing ARIA roles
    - id: missing_roles
      type: grep
      pattern: "<(nav|header|footer|main)(?![^>]*role=)"
      glob: "**/*.{tsx,jsx}"
  verbosity: locations

无障碍检查清单：

• 按钮使用 <button>，而非 <div onClick>
• 图片包含描述性 alt 文本
• 表单输入框有标签或 aria-label
• 焦点状态清晰可见（不要使用 outline: none，除非提供替代方案）
• 颜色对比度符合 WCAG AA 标准（文本为 4.5:1）
• 键盘导航正常工作（Tab 顺序、Enter/Space）

步骤 7.2：检查 ARIA 模式

discover:
  queries:
    # Find custom components
    - id: custom_components
      type: grep
      pattern: "(Accordion|Dialog|Dropdown|Tabs|Tooltip)"
      glob: "src/components/**/*.{tsx,jsx}"
  verbosity: files_only

阅读组件并进行验证：

• 模态框会锁定焦点，并能通过 Escape 关闭
• 下拉菜单支持方向键
• 选项卡支持方向键和 Home/End
• 工具提示可访问（不只是悬停时显示）

阶段 8：评审评分

使用 review-scoring 技能提供结构化反馈。

完整评分标准见 plugins/goodvibes/skills/protocol/review-scoring/SKILL.md。

10 个维度（按权重）：

1. 正确性（15%）- 是否能正常工作？是否满足要求？
2. 类型安全（10%）- TypeScript 使用是否恰当，是否没有 any
3. 安全性（15%）- 是否没有漏洞，是否验证输入并检查身份验证
4. 性能（10%）- 是否没有 N+1 查询，是否使用恰当的索引和记忆化
5. 错误处理（10%）- 是否捕获、记录并处理所有错误
6. 测试（10%）- 测试覆盖率是否足够，断言质量是否良好
7. 代码质量（10%）- 是否易读、易维护并遵循既定模式
8. 架构（10%）- 分层是否恰当，是否没有违规
9. 无障碍（5%）- 语义化 HTML、ARIA、键盘导航
10. 文档（5%）- 需要时是否包含 JSDoc、README 和行内注释

每个维度评分 1–10：

• 1–3：需要重大改进
• 4–6：需要改进
• 7–8：良好，有少量问题
• 9–10：优秀

总分 = 加权平均分

通过/不通过阈值：

• 9.9+：优秀（立即批准）
• 8.0–9.4：良好（批准并提出少量建议）
• 7.0–7.9：可接受（要求修改，存在少量问题）
• 5.0–6.9：需要改进（要求修改，存在重大问题）
• < 5.0：拒绝（需要大幅返工）

阶段 9：自动化验证

运行自动检查以发现问题。

precision_exec:
  commands:
    # Type check
    - cmd: "npm run typecheck"
    # Lint
    - cmd: "npm run lint"
    # Tests
    - cmd: "npm run test"
    # Security audit
    - cmd: "npm audit --audit-level=moderate"
  verbosity: standard

批准前必须通过所有检查。

阶段 10：提供反馈

结构化反馈应具有可操作性，并且具体明确。

评审输出格式：

## Review Summary

**Overall Score**: 8.2/10
**Verdict**: APPROVE with suggestions

**What changed**: Added user profile API with authentication
**Files reviewed**: 8 files (5 source, 3 test)

## Dimension Scores

1. Correctness: 9/10
2. Type Safety: 7/10
3. Security: 9/10
4. Performance: 8/10
5. Error Handling: 7/10
6. Testing: 8/10
7. Code Quality: 9/10
8. Architecture: 8/10
9. Accessibility: 8/10
10. Documentation: 7/10

## Issues Found

### Major (should fix)

- **FILE:LINE** - Type safety: Function `updateProfile` has implicit `any` return type
  - Fix: Add explicit return type `Promise<User>`
  - Impact: TypeScript can't catch type errors in callers

### Minor (nice to fix)

- **src/api/profile.ts:42** - Error handling: Empty catch block swallows errors
  - Fix: Log error with context before re-throwing
  - Impact: Makes debugging harder

## What Was Done Well

- Excellent input validation with Zod schemas
- Comprehensive test coverage (95%)
- Proper authentication checks on all routes
- Clean separation of concerns (route -> service -> repository)

反馈指南：

• 具体明确：包含文件路径和行号
• 可操作：准确说明如何修复
• 说明影响：解释为什么这很重要
• 肯定优秀工作：指出做得好的地方
• 按严重程度分类：严重 > 重大 > 次要

常见评审模式

有关按类别整理的反模式详情，请参阅 references/review-patterns.md。

速查：

安全模式

• SQL 注入：在查询中使用字符串拼接
• XSS：不安全地渲染 HTML
• 绕过身份验证：缺少身份验证检查
• 泄露机密：硬编码 API 密钥

性能模式

• N+1 查询：在循环中调用数据库
• 缺少索引：WHERE 子句未使用索引
• 不必要的重新渲染：React 中使用行内对象
• 内存泄漏：未清理事件监听器

代码质量模式

• 类型不安全：any 类型、类型断言
• 错误处理：未处理的 Promise、空 catch 块
• 复杂度：函数超过 50 行、嵌套超过 3 层
• 重复：复制粘贴代码

测试模式

• 缺少测试：修改的文件没有对应测试
• 断言质量差：expect(result).toBeTruthy()
• 测试污染：测试之间共享状态
• 跳过测试：遗留了 .skip 或 .only

评审精确工具

Discover 工具

并行运行多个 grep/glob 查询以查找模式。

示例：查找安全问题

discover:
  queries:
    - id: sql_injection
      type: grep
      pattern: 'query.*\$\{'
    - id: hardcoded_secrets
      type: grep
      pattern: 'api[_-]?key\s*=\s*["''][^"'']+'
    - id: xss
      type: grep
      pattern: 'dangerouslySetInnerHTML'
  verbosity: locations

Precision Grep

支持上下文、多行搜索和令牌数限制的搜索工具。

示例：查找错误处理

precision_grep:
  queries:
    - id: catch_blocks
      pattern: "try\\s*\\{[\\s\\S]*?\\}\\s*catch"
  output:
    format: context
    context_after: 3
    context_before: 1
  verbosity: standard

Precision Exec

运行验证命令。

precision_exec:
  commands:
    - cmd: "npm run typecheck"
    - cmd: "npm run lint"
    - cmd: "npm test -- --coverage"
  verbosity: standard

验证脚本

使用 scripts/validate-code-review.sh 验证评审是否完整。

./scripts/validate-code-review.sh /path/to/review-output.md

该脚本会检查：

• 是否检查了安全模式
• 是否检查了性能模式
• 是否审查了测试覆盖率
• 是否审查了所有变更文件
• 评审是否包含按评分标准进行的评分
• 反馈是否具体，并附有文件和行号引用

速查指南

审查清单

审查前：

• 理解更改内容（阅读 PR 描述和提交记录）
• 获取差异（git diff 或 GitHub PR）
• 确认已更改的文件及其用途

审查期间：

• 安全性：检查漏洞、身份验证和验证逻辑
• 性能：检查 N+1 问题、索引和重复渲染
• 类型安全：检查 any、类型断言和返回类型
• 错误处理：检查未处理的 Promise 和空的 catch 块
• 测试：检查覆盖率、质量和跳过的测试
• 架构：检查分层、依赖关系和组织结构
• 无障碍：检查语义化 HTML、ARIA 和键盘导航

审查后：

• 运行自动化验证（类型检查、lint、测试）
• 为所有 10 个维度打分
• 计算加权得分
• 给出结论（批准／请求修改／拒绝）
• 提供可执行的反馈，并注明文件和行号

严重程度指南

严重（合并前必须修复）：

• 安全漏洞（SQL 注入、XSS、身份验证绕过）
• 数据丢失错误
• 编译／运行时错误
• 破坏公共 API 的更改

主要（合并前应修复）：

• 类型安全问题（使用 any、缺少类型）
• 性能问题（N+1 查询、缺少索引）
• 缺少错误处理
• 关键路径缺少测试
• 违反架构规范

次要（最好修复，或在后续处理中解决）：

• 代码风格不一致
• 缺少文档
• 非关键的无障碍问题
• 重构机会
• 边缘情况的测试覆盖率较低

应避免的常见错误

虚高评分：

• 存在问题时，不要给出 9–10 分
• 如实说明质量方面的不足
• 存在严重问题时，审查应判定不通过

反馈含糊：

• 不好：“修复类型”
• 好：“src/api/user.ts:42 - 为函数 getUser 添加返回类型 Promise<User>”

忽视优点：

• 始终肯定做得好的地方
• 正面反馈有助于激励改进

严重程度不一致：

• 安全问题始终属于严重问题
• 缺少测试属于主要问题，而非次要问题
• 风格问题属于次要问题，而非主要问题

高级技巧

使用 Discover 批量审查

并行审查多个 PR 或文件。

discover:
  queries:
    - id: all_changes
      type: grep
      pattern: ".*"
      path: "src/"
  verbosity: files_only

然后批量读取文件：

precision_read:
  files:
    - path: "src/changed-file-1.ts"
    - path: "src/changed-file-2.ts"
  extract: content
  output:
    max_per_item: 100
  verbosity: standard

上下文审查

结合上下文使用 precision_grep，以了解周边代码。

precision_grep:
  queries:
    - id: auth_checks
      pattern: "getServerSession|auth\\(\\)"
  output:
    format: context
    context_before: 5
    context_after: 10
  verbosity: standard

差异审查

只关注已更改的行。

precision_exec:
  commands:
    - cmd: "git diff HEAD~1..HEAD --unified=5"
  verbosity: standard

解析差异并只审查已更改的部分。

自动化模式检测

创建一组安全性／性能检查。

discover:
  queries:
    # Security
    - { id: sql_injection, type: grep, pattern: 'query.*\$\{' }
    - { id: xss, type: grep, pattern: 'dangerouslySetInnerHTML' }
    - { id: secrets, type: grep, pattern: 'password\s*=\s*["''][^"'']+' }
    # Performance
    - { id: n_plus_one, type: grep, pattern: 'for.*await.*prisma' }
    - { id: inline_objects, type: grep, pattern: 'onClick=\{\{', glob: '**/*.tsx' }
    # Quality
    - { id: any_usage, type: grep, pattern: ':\s*any', glob: '**/*.ts' }
    - { id: empty_catch, type: grep, pattern: 'catch.*\{\s*\}' }
  verbosity: locations

汇总结果，并根据发现的问题打分。

与其他技能集成

• 使用 review-scoring，依据 10 个维度的评分标准提供结构化反馈
• 在审查修复过程中尝试失败时，使用 error-recovery
• 使用 precision-mastery 掌握高级精准工具用法
• 使用 testing-strategy 验证测试质量
• 审查 UI 组件时，使用 component-architecture
• 审查 API 路由时，使用 api-design
• 审查数据库查询和架构时，使用 database-layer

资源

• references/review-patterns.md - 按类别整理的常见反模式
• scripts/validate-code-review.sh - 自动化审查验证
• plugins/goodvibes/skills/protocol/review-scoring/SKILL.md - 评分标准详情
• OWASP Top 10 - https://owasp.org/www-project-top-ten/
• WCAG 指南 - https://www.w3.org/WAI/WCAG21/quickref/