Back to Details

review-code

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review Workflow

代码审查工作流

Run a comprehensive, multi-perspective code review on the current branch changes. This skill activates the Review Council and integrates automated security scanning to catch issues before they reach a pull request.
[!CAUTION] Scope boundary: This skill reviews code and commits fixes. It does NOT create pull requests, push to remote, or merge anything. When the review is complete, stop and suggest the user run 
/submit-pr
next. Do not proceed to PR creation — that is 
/submit-pr
's job.
[!WARNING] Checkpoint protocol. When this workflow reaches a 
### CHECKPOINT
, you must actively prompt the user for a decision — do not simply present information and continue. Use your agent's interactive prompting mechanism (e.g., 
AskUserQuestion
in Claude Code) to require an explicit response before proceeding. This prevents queued or in-flight messages from being misinterpreted as approval. If your agent lacks interactive prompting, output the checkpoint content and stop all work until the user explicitly responds.
对当前分支的变更进行全面、多维度的代码审查。该技能会激活审查委员会，并集成自动化安全扫描，以便在变更进入拉取请求（Pull Request）前发现问题。
[!CAUTION] 范围边界：本技能仅负责代码审查和提交修复，不创建拉取请求（Pull Request）、推送到远程仓库或执行合并操作。审查完成后，请停止操作，并建议用户下一步运行
/submit-pr
。请勿继续创建PR——这是
/submit-pr
技能的职责。
[!WARNING] 检查点协议：当工作流到达
### CHECKPOINT
时，你必须主动提示用户做出决策——不能仅展示信息就继续执行。请使用Agent的交互式提示机制（例如Claude Code中的
AskUserQuestion
），在继续前获取用户的明确回复。这可以避免将队列中或正在处理的消息误判为批准。如果你的Agent不支持交互式提示，请输出检查点内容并停止所有操作，直到用户给出明确回复。

Step 1: Analyze Current Changes

步骤1：分析当前变更

Identify all changes on the current branch:
  1. Run 
    git diff origin/main...HEAD
    to see all changes relative to main
  2. Run 
    git diff
    and 
    git diff --cached
    to catch any uncommitted work
  3. Run 
    git status
    to see modified, added, and deleted files
Categorize changed files by layer based on your project's directory structure:
  • Frontend: UI components, pages, styles, client-side logic
  • Backend: API routes, services, business logic, server-side code
  • Database: Schema files, migrations, seed data
  • Configuration: Config files, CI/CD, container definitions, environment files
  • Documentation: Markdown files, docs directories
  • Tests: Test files (
    .test.*
    , 
    .spec.*
    )
Present a summary of changed files by category to the user.
识别当前分支上的所有变更：
  1. 运行
    git diff origin/main...HEAD
    查看相对于main分支的所有变更
  2. 运行
    git diff
    和
    git diff --cached
    捕获所有未提交的工作内容
  3. 运行
    git status
    查看已修改、新增和删除的文件
根据项目的目录结构，按层级对变更文件进行分类：
  • 前端：UI组件、页面、样式、客户端逻辑
  • 后端：API路由、服务、业务逻辑、服务端代码
  • 数据库：Schema文件、迁移脚本、种子数据
  • 配置：配置文件、CI/CD配置、容器定义、环境变量文件
  • 文档：Markdown文件、文档目录
  • 测试：测试文件（
    .test.*
    、
    .spec.*
    ）
向用户展示按分类整理的变更文件摘要。

Step 2: Run Formatting and Lint Checks

步骤2：运行格式与代码规范检查

Run your project's formatting and lint commands before the council review to catch mechanical issues early. Common examples:
undefined
在委员会审查前，先运行项目的格式与代码规范检查，提前发现机械性问题。常见示例：
undefined

Adapt to your project's toolchain

根据项目工具链调整

format:check # Prettier, Black, gofmt, etc. lint # ESLint, Ruff, golangci-lint, etc.

If formatting checks fail, fix them immediately by running the auto-formatter on the reported files and stage the changes. Do not include formatting issues in the council review — just fix them.
format:check # Prettier、Black、gofmt等 lint # ESLint、Ruff、golangci-lint等

如果格式检查失败，请立即通过对报告文件运行自动格式化工具来修复问题，并暂存变更。请勿将格式问题提交给委员会审查——直接修复即可。

Step 3: Run Automated Security Scanning

步骤3：运行自动化安全扫描

Perform static application security testing (SAST) on all changed files. Scan for:
<details> <summary>SAST Scanning Checklist</summary>
  • Are all database queries parameterized? (SQL/NoSQL injection)
  • Are user inputs sanitized before rendering? (XSS — reflected, stored, DOM-based)
  • Are state-changing endpoints protected against CSRF?
  • Are there hardcoded secrets, API keys, passwords, or connection strings?
  • Are authentication flows following secure patterns? (no auth bypass paths)
  • Are error messages leaking internal details? (stack traces, DB structure)
  • Are dependencies free of known CVEs?
  • Are file uploads validated and restricted?
  • Are authorization checks present on all protected endpoints?
</details>
If backend files are changed, also perform a hardening review:
  • Is input validation comprehensive on all user-facing inputs?
  • Are authentication and authorization checks present and correct?
  • Are error responses safe? (no internal details leaked)
  • Are secrets managed securely? (environment variables, vaults — not hardcoded)
  • Are security headers configured? (CSP, HSTS, X-Frame-Options)
  • Are rate limits configured on public endpoints?
Collect all findings with severity levels (Critical, High, Medium, Low, Info).
Claude Code optimization: If the 
/security-scanning:security-sast
and 
/security-scanning:security-hardening
skills are available, use them for enhanced automated scanning. Otherwise, follow the manual checklists above.
对所有变更文件执行静态应用安全测试（SAST）。扫描内容包括：
<details> <summary>SAST扫描检查清单</summary>
  • 所有数据库查询是否都使用了参数化？（防范SQL/NoSQL注入）
  • 用户输入在渲染前是否经过清理？（防范XSS——反射型、存储型、DOM型）
  • 状态变更的端点是否受到CSRF防护？
  • 是否存在硬编码的密钥、API密钥、密码或连接字符串？
  • 认证流程是否遵循安全模式？（无认证绕过路径）
  • 错误信息是否泄露内部细节？（堆栈跟踪、数据库结构）
  • 依赖项是否存在已知的CVE漏洞？
  • 文件上传是否经过验证和限制？
  • 所有受保护的端点是否都有授权检查？
</details>
如果有后端文件变更，还需执行强化审查：
  • 所有面向用户的输入是否都经过全面验证？
  • 认证和授权检查是否存在且正确？
  • 错误响应是否安全？（未泄露内部细节）
  • 密钥是否得到安全管理？（使用环境变量、密钥管理系统——而非硬编码）
  • 是否配置了安全头？（CSP、HSTS、X-Frame-Options）
  • 公共端点是否配置了速率限制？
收集所有发现的问题，并标注严重级别（Critical、High、Medium、Low、Info）。
Claude Code优化建议：如果
/security-scanning:security-sast
和
/security-scanning:security-hardening
技能可用，请使用它们来增强自动化扫描。否则，请遵循上述手动检查清单。

Step 4: Run Accessibility Audit (if frontend changes)

步骤4：可访问性审计（若有前端变更）

If any frontend files (UI components, CSS, HTML templates) are in the changeset, check WCAG compliance on modified components:
<details> <summary>Accessibility Checklist</summary>
  • Do text and interactive elements meet color contrast ratios? (4.5:1 for normal text, 3:1 for large text)
  • Can all interactive elements be reached and operated via keyboard alone?
  • Are ARIA attributes used correctly? (roles, labels, live regions)
  • Is focus managed properly during dynamic content changes? (modals, route transitions)
  • Is semantic HTML used? (
    <button>
    not 
    <div onClick>
    , 
    <nav>
    , 
    <main>
    , 
    <article>
    )
  • Are images and icons given accessible names? (
    alt
    text, 
    aria-label
    )
  • Are form inputs associated with labels?
  • Does the page make sense when read linearly by a screen reader?
</details>
Claude Code optimization: If the 
/ui-design:accessibility-audit
skill is available, use it for enhanced automated WCAG compliance checking. Otherwise, follow the manual checklist above.
如果变更集中包含前端文件（UI组件、CSS、HTML模板），请检查修改后组件的WCAG合规性：
<details> <summary>可访问性检查清单</summary>
  • 文本和交互元素是否符合颜色对比度要求？（普通文本4.5:1，大文本3:1）
  • 所有交互元素是否仅通过键盘即可访问和操作？
  • ARIA属性是否使用正确？（角色、标签、实时区域）
  • 动态内容变更时（模态框、路由切换），焦点是否得到正确管理？
  • 是否使用了语义化HTML？（使用
    <button>
    而非
    <div onClick>
    、
    <nav>
    、
    <main>
    、
    <article>
    ）
  • 图片和图标是否有可访问的名称？（
    alt
    文本、
    aria-label
    ）
  • 表单输入是否与标签关联？
  • 屏幕阅读器线性读取页面时是否逻辑通顺？
</details>
Claude Code优化建议：如果
/ui-design:accessibility-audit
技能可用，请使用它来增强自动化WCAG合规性检查。否则，请遵循上述手动检查清单。

Step 5: Activate the Review Council

步骤5：激活审查委员会

Read the Review Council template from the skill's 
councils/review-council.md
and conduct the full council review. For each council member, read their agent definition from the skill's 
agents/
directory and use the complexity tier specified to calibrate review depth.
从技能的
councils/review-council.md
中读取审查委员会模板，开展完整的委员会审查。对于每位委员会成员，请从技能的
agents/
目录中读取其Agent定义，并使用指定的复杂度层级来调整审查深度。

Security Engineer (Lead)

安全工程师（负责人）

  • Review all SAST findings from Step 3
  • Check for OWASP Top 10 vulnerabilities in the changed code
  • Validate input sanitization on any new endpoints or forms
  • Check secrets management (no hardcoded credentials, API keys, tokens)
  • Verify authentication and authorization logic
  • Vote: Approve / Concern / Block
  • Findings: List each issue with severity and file location
  • Recommendations: Specific fixes for each finding
  • 审查步骤3中所有SAST发现的问题
  • 检查变更代码中是否存在OWASP Top 10漏洞
  • 验证任何新端点或表单的输入清理逻辑
  • 检查密钥管理（无硬编码凭证、API密钥、令牌）
  • 验证认证与授权逻辑
  • 投票：批准 / 关注 / 阻止
  • 发现的问题：列出每个问题的严重级别和文件位置
  • 建议：每个问题的具体修复方案

QA Lead

QA负责人

  • Assess test coverage for changed files
  • Check if new functionality has corresponding tests
  • Identify untested edge cases and boundary conditions
  • Verify error scenarios are tested
  • Check if test coverage meets the >80% target
  • Vote: Approve / Concern / Block
  • Findings: Missing tests, coverage gaps, untested scenarios
  • Recommendations: Specific tests to add
  • 评估变更文件的测试覆盖率
  • 检查新功能是否有对应的测试用例
  • 识别未测试的边缘情况和边界条件
  • 验证错误场景是否已覆盖测试
  • 检查测试覆盖率是否达到>80%的目标
  • 投票：批准 / 关注 / 阻止
  • 发现的问题：缺失的测试、覆盖率缺口、未测试场景
  • 建议：需要添加的具体测试用例

DevX Engineer

DevX工程师

  • Check if documentation is updated for user-facing changes
  • Review code readability and clarity of complex logic
  • Verify README/docs reflect any new features or changes
  • Check that public APIs have proper documentation comments
  • Vote: Approve / Concern / Block
  • Findings: Documentation gaps, unclear code sections
  • Recommendations: Documentation and clarity improvements
  • 检查面向用户的变更是否已更新文档
  • 审查代码可读性和复杂逻辑的清晰度
  • 验证README/文档是否反映了所有新功能或变更
  • 检查公共API是否有适当的文档注释
  • 投票：批准 / 关注 / 阻止
  • 发现的问题：文档缺口、代码模糊部分
  • 建议：文档和代码清晰度的改进方案

Domain Specialist

领域专家

Select the appropriate specialist based on changed files:
  • Frontend Specialist if frontend files changed
  • Backend Specialist if backend files changed
  • Both if changes span frontend and backend
Review domain-specific best practices:
  • Component patterns, state management, rendering performance (frontend)
  • Framework patterns, service architecture, API design (backend)
  • Schema design, query optimization, migration safety (database)
  • Vote: Approve / Concern / Block
  • Findings: Pattern violations, anti-patterns, performance concerns
  • Recommendations: Specific improvements
根据变更文件选择合适的专家：
  • 若有前端文件变更，选择前端专家
  • 若有后端文件变更，选择后端专家
  • 若变更同时涉及前端和后端，则同时选择两者
审查领域特定的最佳实践：
  • 组件模式、状态管理、渲染性能（前端）
  • 框架模式、服务架构、API设计（后端）
  • Schema设计、查询优化、迁移安全性（数据库）
  • 投票：批准 / 关注 / 阻止
  • 发现的问题：模式违规、反模式、性能问题
  • 建议：具体的改进方案

Step 6: Present Consolidated Review Report

步骤6：呈现整合后的审查报告

Present the full review report organized by severity:
按严重级别整理并呈现完整的审查报告：

Critical / Blocking Issues

关键/阻塞问题

Issues that must be fixed before merge (any Block vote or Critical SAST finding).
合并前必须修复的问题（任何“阻止”投票或关键级SAST发现）。

High Priority Issues

高优先级问题

Issues strongly recommended to fix (High SAST findings, Concern votes with security implications).
强烈建议修复的问题（高级别SAST发现、具有安全影响的“关注”投票）。

Medium Priority Issues

中优先级问题

Issues worth fixing but not blocking (Medium SAST findings, code quality concerns).
值得修复但不阻塞合并的问题（中等级别SAST发现、代码质量问题）。

Low Priority / Suggestions

低优先级/建议

Nice-to-have improvements (Low findings, style suggestions, minor documentation gaps).
锦上添花的改进（低级别发现、样式建议、次要文档缺口）。

Review Decision Summary

审查决策摘要

  • Overall Status: Approved / Needs Changes / Blocked
  • Council Votes: Summary of each member's vote
  • Action Items: Prioritized list of what to fix
  • 整体状态：已批准 / 需要修改 / 已阻塞
  • 委员会投票：每位成员的投票摘要
  • 行动项：按优先级排序的修复清单

CHECKPOINT: Present all findings to the user. Ask which items they want to address now. Wait for instructions before proceeding.

CHECKPOINT: 向用户展示所有发现的问题，询问他们现在想要处理哪些项。等待用户指示后再继续。

Step 7: Apply Fixes

步骤7：应用修复

For each item the user approves for fixing:
  1. Apply the fix
  2. Re-run the relevant check (lint, test, type-check, or security scan) to verify the fix
  3. Stage the changes
If the user asks to skip certain findings, note them as deferred items for Step 9.
对于用户批准修复的每个问题：
  1. 应用修复
  2. 重新运行相关检查（代码规范、测试、类型检查或安全扫描）以验证修复效果
  3. 暂存变更
如果用户要求跳过某些发现的问题，请将其标记为延迟处理项，留到步骤9处理。

CHECKPOINT: Present the applied fixes to the user. Confirm all changes look correct before committing.

CHECKPOINT: 向用户展示已应用的修复，在提交前确认所有变更都正确无误。

Step 8: Commit

步骤8：提交变更

If the user approves:
  1. Stage all changes
  2. Commit with an appropriate conventional commit message (e.g., 
    fix(security): address SAST findings
    or 
    refactor: address code review feedback
    )
如果用户批准：
  1. 暂存所有变更
  2. 使用合适的约定式提交消息提交（例如
    fix(security): address SAST findings
    或
    refactor: address code review feedback
    ）

Step 9: Track Deferred Work

步骤9：跟踪延迟处理的工作

If any review findings were deferred (not fixed in this cycle), document them so they don't get lost.
如果有任何审查发现的问题被延迟处理（未在本次周期中修复），请记录下来以免遗漏。

Check for Deferred Items

检查延迟处理项

Review the following sources for deferred work:
  1. Skipped findings: Items the user chose not to address from the review report
  2. Low priority suggestions: Items categorized as Low/Info that weren't fixed
  3. Council recommendations: Improvements suggested by council members that are out of scope for this PR
从以下来源梳理延迟处理的工作：
  1. 跳过的问题：用户选择不处理的审查发现项
  2. 低优先级建议：归类为低级别/信息性且未修复的项
  3. 委员会建议：委员会成员提出的、超出本次PR范围的改进建议

Document Deferred Work

记录延迟处理的工作

For each deferred item, create a tracking issue in your project's issue tracker with the finding description, context on why it was deferred, and what needs to happen.
[!TIP] Not every review generates deferred work. If all findings were addressed or accepted, skip this step entirely. Don't manufacture follow-up issues just to have them.
对于每个延迟处理项，在项目的问题跟踪器中创建一个跟踪议题，包含问题描述、延迟处理的原因说明以及需要完成的工作内容。
[!TIP] 并非每次审查都会产生延迟处理的工作。如果所有发现的问题都已处理或被接受，请直接跳过此步骤。不要为了创建后续议题而刻意编造内容。

Step 10: Hand Off — STOP Here

步骤10：交接——在此停止

[!CAUTION] This skill's work is done. Do NOT proceed to create a pull request, push to remote, or merge anything. Those are separate skills with their own workflows and checkpoints.
Suggest the next step — then stop:
  • If ready for PR: "Run 
    /submit-pr
    to create a pull request"
  • If more work needed: "Continue implementation, then run 
    /review-code
    again when ready"
Do not push the branch, create a PR, or invoke 
/submit-pr
from within this skill.
[!CAUTION] 本技能的工作已完成。请勿继续创建拉取请求、推送到远程仓库或执行合并操作。这些是独立技能的职责，有各自的工作流和检查点。
建议下一步操作——然后停止：
  • 若准备好创建PR：“运行
    /submit-pr
    来创建拉取请求”
  • 若还需要更多工作：“继续开发，准备就绪后再次运行
    /review-code
    ”
请勿在本技能中推送分支、创建PR或调用
/submit-pr
。