code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code Review — Deep Codebase Audit Skill

Code Review — 深度代码库审计Skill

You perform a thorough, multi-pass audit of a codebase looking for real problems — not style nits. You find the gaps that cause bugs in production: functions nobody calls, errors nobody sees, features half-built, and code that should be deleted.

你将对代码库进行全面的多轮审计，寻找实际问题而非格式规范问题。你会找出导致生产环境Bug的隐患：无人调用的函数、无人察觉的错误、未完成的功能以及应删除的代码。

CRITICAL RULES

核心规则

Every finding must include
file:line
references. No vague "somewhere in the code" findings.
Categorize by severity. CRITICAL > WARNING > PRUNE > INFO. Read
```
resources/severity-guide.md
```
.
Run ALL passes. Don't skip passes because early ones found nothing. Read
```
resources/audit-passes.md
```
.
Never suggest adding code without showing what to remove. This is a pruning exercise, not a feature request.
Focus on real bugs, not style. Don't flag formatting, naming conventions, or missing comments unless they actively cause confusion or bugs.
Provide the fix, not just the finding. Each finding should say what to do about it.

所有发现必须包含
file:line
引用。禁止模糊的“代码中某处”这类描述。
按严重程度分类。优先级为：CRITICAL（严重）> WARNING（警告）> PRUNE（可精简）> INFO（信息）。请阅读
```
resources/severity-guide.md
```
。
执行所有审计轮次。不要因前期未发现问题就跳过轮次。请阅读
```
resources/audit-passes.md
```
。
禁止只建议添加代码却不说明要删除的内容。这是一次代码精简工作，而非功能需求请求。
聚焦实际Bug，而非格式规范。除非格式、命名规范或缺失注释会直接导致混淆或Bug，否则无需标记。
不仅要指出问题，还要提供修复方案。每个发现都应说明解决措施。

Audit Architecture

审计架构

The review runs 7 passes over the codebase. Each pass looks for a different class of problem. The passes are ordered from most critical (broken functionality) to least critical (cleanup opportunities).

Pass 1: WIRING          — Is everything connected end-to-end?
Pass 2: ERROR HANDLING   — Can failures be seen and debugged?
Pass 3: COMPLETENESS     — Are features fully implemented?
Pass 4: DEAD CODE        — What can be deleted right now?
Pass 5: BLOAT            — What's too big, too complex, or redundant?
Pass 6: HARDCODING       — What should be configurable but isn't?
Pass 7: SECURITY         — Any obvious vulnerabilities?

Read

resources/audit-passes.md

for the detailed checklist for each pass.

评审会对代码库执行7轮审计，每轮针对不同类型的问题。轮次按影响程度从高到低排序：从严重的功能故障到次要的代码清理机会。

Pass 1: WIRING          — 所有模块是否端到端连通？
Pass 2: ERROR HANDLING   — 故障是否可被察觉和调试？
Pass 3: COMPLETENESS     — 功能是否完全实现？
Pass 4: DEAD CODE        — 哪些代码可立即删除？
Pass 5: BLOAT            — 哪些代码过于庞大、复杂或冗余？
Pass 6: HARDCODING       — 哪些内容应可配置却被硬编码？
Pass 7: SECURITY         — 是否存在明显的漏洞？

请阅读

resources/audit-passes.md

获取每轮审计的详细检查清单。

Workflow

工作流程

Phase 1 — Scope the Review

阶段1 — 确定评审范围

Before auditing, understand the codebase:

What's the project? Read README, CLAUDE.md, package.json, etc.
What's the tech stack? Framework, language, build tools
What's the architecture? Entry points, services, stores, components
What was recently changed? If there's git history, focus on recent additions

Build a mental map of the codebase:

Entry point → Router → Pages → Components → Stores → Services → External APIs
Trace the full data flow from user action to persistence and back

审计前，先了解代码库：

项目定位？ 阅读README、CLAUDE.md、package.json等文件。
技术栈？ 框架、语言、构建工具
架构？ 入口点、服务、状态存储、组件
近期变更？ 如果有Git历史记录，重点关注近期新增内容

构建代码库的心智模型：

入口点 → 路由 → 页面 → 组件 → 状态存储 → 服务 → 外部API
追踪从用户操作到数据持久化再返回的完整数据流

Phase 2 — Run the 7 Audit Passes

阶段2 — 执行7轮审计

For each pass, use Grep and Glob to systematically search for the patterns described in

resources/audit-passes.md

Use parallel agents when the codebase is large. Spawn agents for independent passes:

Agent 1: Passes 1-2 (Wiring + Error Handling) — these are related
Agent 2: Passes 3-4 (Completeness + Dead Code) — these are related
Agent 3: Passes 5-7 (Bloat + Hardcoding + Security) — lighter passes

每轮审计中，使用Grep和Glob系统搜索

resources/audit-passes.md

中描述的模式。

代码库较大时，使用并行Agent。为独立的审计轮次分配Agent：

Agent 1：第1-2轮（Wiring + 错误处理）—— 二者相关
Agent 2：第3-4轮（功能完整性 + 死代码）—— 二者相关
Agent 3：第5-7轮（代码臃肿 + 硬编码 + 安全）—— 相对轻量的轮次

Phase 3 — Cross-Reference

阶段3 — 交叉验证

After individual passes, cross-reference findings:

Does a "dead code" finding explain a "wiring" gap? (function exists but never called)
Does a "completeness" gap overlap with a "placeholder" finding?
Deduplicate — one root cause might show up in multiple passes

完成各轮审计后，交叉验证发现的问题：

“死代码”的发现是否能解释“连接”漏洞？（函数存在但从未被调用）
“功能完整性”的漏洞是否与“占位符”发现重叠？
去重——同一个根因可能在多轮审计中出现

Phase 4 — Compile the Report

阶段4 — 生成报告

Output format (read

resources/report-format.md

markdown

undefined

输出格式（请阅读

resources/report-format.md

）：

markdown

undefined

Code Review Report — [Project Name]

代码评审报告 — [项目名称]

Date: [date] Files Scanned: [count] Findings: [count] (X critical, Y warning, Z prune, W info)

日期: [日期] 扫描文件数: [数量] 发现问题数: [数量]（X个严重，Y个警告，Z个可精简，W个信息）

CRITICAL — Must Fix

CRITICAL（严重）— 必须修复

These cause broken functionality, data loss, or security holes.

此类问题会导致功能故障、数据丢失或安全漏洞。

CR-001: [Title]

CR-001: [标题]

File:

src/stores/game-store.ts:108

Pass: Wiring Problem:

submitGameSession()

is defined in dataverse.ts but never called. Game results are never persisted to Dataverse. Fix: Call

submitGameSession()

from the

endGame()

action in game-store.ts.

文件:

src/stores/game-store.ts:108

审计轮次: Wiring 问题:

submitGameSession()

在dataverse.ts中定义但从未被调用。游戏结果从未持久化到Dataverse。 修复方案: 在game-store.ts的

endGame()

动作中调用

submitGameSession()

。

WARNING — Should Fix

WARNING（警告）— 建议修复

These cause degraded experience, silent failures, or maintainability issues.

此类问题会导致体验下降、静默故障或可维护性问题。

PRUNE — Consider Removing

PRUNE（可精简）— 考虑移除

Dead code, redundant logic, bloated files. Removing these makes the codebase leaner and easier to maintain.

死代码、冗余逻辑、臃肿文件。移除这些内容可使代码库更精简、更易维护。

INFO — Minor Observations

INFO（信息）— 次要观察

Nice-to-know items that don't require action.

undefined

无需处理的实用信息。

undefined

Phase 5 — Pruning Recommendations

阶段5 — 精简建议

After the main audit, generate a pruning plan. Read

resources/pruning-guide.md

The pruning plan should:

List files/functions/types that can be safely deleted
List files that should be split (too many responsibilities)
List abstractions that should be inlined (used only once)
List dependencies that can be removed from package.json
Estimate the total lines of code that would be removed

主审计完成后，生成精简计划。请阅读

resources/pruning-guide.md

。

精简计划应包含：

列出可安全删除的文件/函数/类型
列出应拆分的文件（职责过多）
列出应内联的抽象（仅被使用一次）
列出可从package.json中移除的依赖
估算可删除的代码总行数

Without Agent Teams

无Agent团队时的处理方式

If running as a single agent, execute passes sequentially. Prioritize passes 1-3 (Wiring, Error Handling, Completeness) as these find the most impactful issues. Passes 4-7 are still valuable but can be deferred if time-constrained.

如果以单个Agent运行，按顺序执行各轮审计。优先执行第1-3轮（Wiring、错误处理、功能完整性），因为这些轮次能发现影响最大的问题。第4-7轮仍有价值，但如果时间紧张可延后处理。