backend-code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Backend Code Review

后端代码审查

When to use this skill

何时使用此技能

Use this skill whenever the user asks to review, analyze, or improve backend code (e.g.,

.py

) under the

api/

directory. Supports the following review modes:

Pending-change review: when the user asks to review current changes (inspect staged/working-tree files slated for commit to get the changes).
Code snippets review: when the user pastes code snippets (e.g., a function/class/module excerpt) into the chat and asks for a review.
File-focused review: when the user points to specific files and asks for a review of those files (one file or a small, explicit set of files, e.g.,
```
api/...
```
,
```
api/app.py
```
).

Do NOT use this skill when:

The request is about frontend code or UI (e.g.,
```
.tsx
```
,
```
.ts
```
,
```
.js
```
,
```
web/
```
).
The user is not asking for a review/analysis/improvement of backend code.
The scope is not under
```
api/
```
(unless the user explicitly asks to review backend-related changes outside
```
api/
```
).

当用户要求审查、分析或改进

api/

目录下的后端代码（如

.py

）时，即可使用此技能。支持以下审查模式：

待变更审查：当用户要求审查当前变更时（检查已暂存/工作目录中待提交的文件以获取变更内容）。
代码片段审查：当用户将代码片段（如函数/类/模块节选）粘贴到聊天中并要求审查时。
聚焦文件审查：当用户指向特定文件并要求审查这些文件时（单个文件或少量明确指定的文件，例如
```
api/...
```
、
```
api/app.py
```
）。

请勿在以下场景使用此技能：

请求涉及前端代码或UI（如
```
.tsx
```
、
```
.ts
```
、
```
.js
```
、
```
web/
```
）时。
用户未要求审查/分析/改进后端代码时。
范围不在
```
api/
```
目录下时（除非用户明确要求审查
```
api/
```
目录外的后端相关变更）。

How to use this skill

如何使用此技能

Follow these steps when using this skill:

Identify the review mode (pending-change vs snippet vs file-focused) based on the user’s input. Keep the scope tight: review only what the user provided or explicitly referenced.
Follow the rules defined in Checklist to perform the review. If no Checklist rule matches, apply General Review Rules as a fallback to perform the best-effort review.
Compose the final output strictly follow the Required Output Format.

Notes when using this skill:

Always include actionable fixes or suggestions (including possible code snippets).
Use best-effort
```
File:Line
```
references when a file path and line numbers are available; otherwise, use the most specific identifier you can.

使用此技能时请遵循以下步骤：

确定审查模式（待变更、代码片段或聚焦文件），依据用户输入而定。严格控制范围：仅审查用户提供或明确提及的内容。
按照检查清单中定义的规则执行审查。如果没有匹配的检查清单规则，则以通用审查规则作为 fallback，尽最大努力完成审查。
严格按照要求的输出格式撰写最终结果。

使用此技能的注意事项：

始终包含可操作的修复方案或建议（包括可能的代码片段）。
如果有文件路径和行号可用，尽量使用
```
File:Line
```
格式的引用；否则，使用最具体的标识符。

Checklist

检查清单

db schema design: if the review scope includes code/files under
```
api/models/
```
or
```
api/migrations/
```
, follow references/db-schema-rule.md to perform the review
architecture: if the review scope involves controller/service/core-domain/libs/model layering, dependency direction, or moving responsibilities across modules, follow references/architecture-rule.md to perform the review
repositories abstraction: if the review scope contains table/model operations (e.g.,
```
select(...)
```
,
```
session.execute(...)
```
, joins, CRUD) and is not under
```
api/repositories
```
,
```
api/core/repositories
```
, or
```
api/extensions/*/repositories/
```
, follow references/repositories-rule.md to perform the review
sqlalchemy patterns: if the review scope involves SQLAlchemy session/query usage, db transaction/crud usage, or raw SQL usage, follow references/sqlalchemy-rule.md to perform the review

数据库 schema 设计：如果审查范围包含
```
api/models/
```
或
```
api/migrations/
```
下的代码/文件，请遵循references/db-schema-rule.md执行审查
架构：如果审查范围涉及控制器/服务/核心领域/库/模型分层、依赖方向或跨模块职责转移，请遵循references/architecture-rule.md执行审查
仓库抽象：如果审查范围包含表/模型操作（如
```
select(...)
```
、
```
session.execute(...)
```
、连接、CRUD）且不在
```
api/repositories
```
、
```
api/core/repositories
```
或
```
api/extensions/*/repositories/
```
目录下，请遵循references/repositories-rule.md执行审查
SQLAlchemy 模式：如果审查范围涉及SQLAlchemy会话/查询使用、数据库事务/CRUD使用或原生SQL使用，请遵循references/sqlalchemy-rule.md执行审查

General Review Rules

通用审查规则

1. Security Review

1. 安全审查

Check for:

SQL injection vulnerabilities
Server-Side Request Forgery (SSRF)
Command injection
Insecure deserialization
Hardcoded secrets/credentials
Improper authentication/authorization
Insecure direct object references

检查以下内容：

SQL注入漏洞
服务器端请求伪造（SSRF）
命令注入
不安全的反序列化
硬编码的密钥/凭证
不当的认证/授权
不安全的直接对象引用

2. Performance Review

2. 性能审查

Check for:

N+1 queries
Missing database indexes
Memory leaks
Blocking operations in async code
Missing caching opportunities

检查以下内容：

N+1查询问题
缺失的数据库索引
内存泄漏
异步代码中的阻塞操作
可缓存但未缓存的场景

3. Code Quality Review

3. 代码质量审查

Check for:

Code forward compatibility
Code duplication (DRY violations)
Functions doing too much (SRP violations)
Deep nesting / complex conditionals
Magic numbers/strings
Poor naming
Missing error handling
Incomplete type coverage

检查以下内容：

代码向前兼容性
代码重复（违反DRY原则）
函数职责过多（违反单一职责原则）
深层嵌套/复杂条件判断
魔术数字/字符串
命名不规范
缺失错误处理
类型覆盖不完整

4. Testing Review

4. 测试审查

Check for:

Missing test coverage for new code
Tests that don't test behavior
Flaky test patterns
Missing edge cases

检查以下内容：

新代码缺失测试覆盖
未测试实际行为的测试用例
不稳定的测试模式
缺失边缘场景测试

Required Output Format

要求的输出格式

When this skill invoked, the response must exactly follow one of the two templates:

当调用此技能时，响应必须严格遵循以下两个模板之一：

Template A (any findings)

模板A（存在问题）

markdown

undefined

markdown

undefined

Code Review Summary

代码审查总结

Found <X> critical issues need to be fixed:

发现 <X> 个关键问题需要修复：

🔴 Critical (Must Fix)

🔴 关键问题（必须修复）

1. <brief description of the issue>

1. <问题简要描述>

FilePath: <path> line <line> <relevant code snippet or pointer>

文件路径：<路径> 行 <行号> <相关代码片段或引用>

Explanation

说明

<问题的详细解释及参考依据>

Suggested Fix

建议修复方案

<brief description of suggested fix>
<code example> (optional, omit if not applicable)

... (repeat for each critical issue) ...

Found <Y> suggestions for improvement:

<修复方案简要描述>
<代码示例>（可选，不适用则省略）

...（每个关键问题重复上述结构）...

发现 <Y> 个改进建议：

🟡 Suggestions (Should Consider)

🟡 改进建议（建议考虑）

1. <brief description of the suggestion>

1. <建议简要描述>

FilePath: <path> line <line> <relevant code snippet or pointer>

文件路径：<路径> 行 <行号> <相关代码片段或引用>

Explanation

说明

<建议的详细解释及参考依据>

Suggested Fix

建议修复方案

<brief description of suggested fix>
<code example> (optional, omit if not applicable)

... (repeat for each suggestion) ...

Found <Z> optional nits:

<修复方案简要描述>
<代码示例>（可选，不适用则省略）

...（每个改进建议重复上述结构）...

发现 <Z> 个可选优化点：

🟢 Nits (Optional)

🟢 可选优化点（可选）

1. <brief description of the nit>

1. <优化点简要描述>

FilePath: <path> line <line> <relevant code snippet or pointer>

文件路径：<路径> 行 <行号> <相关代码片段或引用>

Explanation

说明

<可选优化点的解释及参考依据>

Suggested Fix

建议修复方案

<minor suggestions>

... (repeat for each nits) ...

<小建议>

...（每个可选优化点重复上述结构）...

✅ What's Good

✅ 亮点

<Positive feedback on good patterns>


- If there are no critical issues or suggestions or option nits or good points, just omit that section.
- If the issue number is more than 10, summarize as "Found 10+ critical issues/suggestions/optional nits" and only output the first 10 items.
- Don't compress the blank lines between sections; keep them as-is for readability.
- If there is any issue requires code changes, append a brief follow-up question to ask whether the user wants to apply the fix(es) after the structured output. For example: "Would you like me to use the Suggested fix(es) to address these issues?"

<对良好代码模式的正面反馈>


- 如果没有关键问题、改进建议、可选优化点或亮点，直接省略对应章节。
- 如果问题数量超过10个，总结为“发现10+个关键问题/改进建议/可选优化点”，仅输出前10项。
- 不要压缩章节之间的空白行，保持原样以提升可读性。
- 如果有任何需要代码变更的问题，在结构化输出后追加一个简短的跟进问题，询问用户是否希望应用修复方案。例如：“是否需要我使用上述建议的修复方案来解决这些问题？”

Template B (no issues)

Template B（无问题）

markdown

undefined

markdown

undefined

Code Review Summary

代码审查总结

✅ No issues found.

undefined

✅ 未发现任何问题。

undefined