review-style-guide

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Style Guide Review

风格指南审查

Review the current code changes against this project's coding style guide and conventions.

对照项目的编码风格指南和约定审查当前的代码变更。

Process

流程

Step 1: Load the Style Guide

步骤1：加载风格指南

Look for the style guide in this order:

```
STYLE_GUIDE.md
```
in the project root
```
.claude/style-guide.md
```
The "Conventions" section of
```
CLAUDE.md
```
or
```
AGENTS.md
```

If none exist, stop and tell the user:

No style guide found. Run
/setup-ai
to generate one, or
/generate-comprehensive-style-guide
for a deeper analysis.

按以下顺序查找风格指南：

项目根目录下的
```
STYLE_GUIDE.md
```
```
.claude/style-guide.md
```
```
CLAUDE.md
```
或
```
AGENTS.md
```
中的「约定」章节

如果未找到任何风格指南，请停止并告知用户：

未找到风格指南。请运行
/setup-ai
生成，如需更深度的分析可运行
/generate-comprehensive-style-guide
。

Step 2: Get the Changes

步骤2：获取变更内容

Determine what to review:

$ARGUMENTS

is provided, treat it as the base to diff against:

```
/review-style main
```
→
```
git diff main...HEAD
```
```
/review-style HEAD~3
```
→
```
git diff HEAD~3
```

If no arguments:
- Check
```
git diff --cached
```
  — staged changes (preferred, about to be committed)
- If nothing staged, check
```
git diff
```
  — unstaged changes
- If nothing modified, check
```
git diff HEAD~1
```
  — last commit

If there are no changes anywhere, tell the user: "No changes to review."

确定需要审查的内容范围：

如果提供了

$ARGUMENTS

，将其作为对比的基准版本：

```
/review-style main
```
→
```
git diff main...HEAD
```
```
/review-style HEAD~3
```
→
```
git diff HEAD~3
```

如果未提供参数：
- 检查
```
git diff --cached
```
  — 暂存区变更（优先选择，对应即将提交的代码）
- 如果没有暂存的变更，检查
```
git diff
```
  — 未暂存的变更
- 如果没有任何修改内容，检查
```
git diff HEAD~1
```
  — 最近一次提交

如果所有位置都没有变更，告知用户："没有可审查的变更内容。"

Step 3: Review Each Changed File

步骤3：审查每个变更文件

For every file in the diff, check against the style guide:

Naming:

Do new variables, functions, and classes follow the naming conventions?
Do new files follow the file naming pattern?
Do database columns/tables follow the naming pattern?

Code Organization:

Are imports ordered correctly per the style guide?
Does the file follow the standard internal structure (imports → types → logic → exports)?
Are new files in the right directory?

Patterns:

Does error handling follow the project's documented pattern?
Are new tests structured like existing tests (same framework, same describe/it pattern)?
Do new API endpoints follow the established conventions?
Do new components follow the component pattern (if frontend)?

Anti-Patterns:

Does the new code use any patterns listed under "Anti-Patterns — Do NOT Replicate"?
Does it introduce deprecated approaches the team is moving away from?

对diff中的每个文件，对照风格指南检查以下项：

命名：

新增的变量、函数、类是否符合命名约定？
新增文件是否符合文件命名规则？
数据库列/表是否符合命名规则？

代码组织：

导入语句是否按照风格指南要求正确排序？
文件是否遵循标准内部结构（导入 → 类型定义 → 逻辑代码 → 导出）？
新增文件是否放在正确的目录下？

模式：

错误处理是否符合项目记录的模式？
新增测试是否和现有测试结构一致（相同框架、相同的describe/it模式）？
新增API端点是否遵循既定约定？
新增组件是否遵循组件模式（前端项目）？

反模式：

新代码是否使用了「反模式 — 禁止复用」下列出的任何模式？
是否引入了团队正在淘汰的废弃方案？

Step 4: Report Findings

步骤4：反馈审查结果

For each issue, use this format:

🔴 MUST FIX — [file]:[line]
   [Description of the violation]
   Style guide says: [quote or paraphrase the relevant rule]
   Code does: [what the code actually does]
   Suggested fix: [specific change to make]

🟡 SHOULD FIX — [file]:[line]
   [Description]
   Style guide says: [rule]
   Code does: [actual]
   Suggested fix: [change]

🟢 CONSIDER — [file]:[line]
   [Description and reasoning]

Severity definitions:

🔴 Must fix: Clearly violates a documented convention in the style guide
🟡 Should fix: Deviates from common patterns in the codebase but not explicitly documented as a rule
🟢 Consider: Stylistic choice worth noting — could go either way

每个问题使用以下格式输出：

🔴 必须修复 — [文件]:[行号]
   [违规描述]
   风格指南规定：[引用或释义相关规则]
   代码实际实现：[代码的实际行为]
   修复建议：[具体的修改内容]

🟡 建议修复 — [文件]:[行号]
   [描述]
   风格指南规定：[规则]
   代码实际实现：[实际行为]
   修复建议：[修改内容]

🟢 可考虑优化 — [文件]:[行号]
   [描述和理由]

严重程度定义：

🔴 必须修复： 明确违反风格指南中记录的约定
🟡 建议修复： 与代码库通用模式存在偏差，但未被明确记录为规则
🟢 可考虑优化： 值得注意的风格选择，两种方案都可接受

Step 5: Summary

步骤5：总结

End with:

undefined

结尾附上：

undefined

Review Summary

审查总结

Files reviewed: [count]
Issues found: [count] 🔴 / [count] 🟡 / [count] 🟢
Verdict: [PASS — code matches project conventions / NEEDS CHANGES — see issues above]

undefined

已审查文件数：[数量]
发现问题数：[数量] 🔴 / [数量] 🟡 / [数量] 🟢
结论：[通过 — 代码符合项目约定 / 需要修改 — 参见上方问题列表]

undefined

Rules

规则

Only flag actual deviations. Don't impose personal preferences that aren't in the style guide.
Be specific. "Line 42 uses camelCase but style guide specifies snake_case for function names" — not "naming is inconsistent."
Cite the style guide rule. Every 🔴 and 🟡 must reference which section of the style guide is being violated.
If the style guide is ambiguous, mark as 🟢 CONSIDER, never 🔴 MUST FIX.
If the code is clean, say so: "No style guide violations found. Code matches project conventions."
Don't review generated files (lock files, build output, auto-generated types). Focus on human-authored source code.

仅标记实际存在的偏差。 不要强加风格指南中未提及的个人偏好。
表述具体。 例如要写「第42行使用了camelCase，但风格指南规定函数名使用snake_case」，不要写「命名不一致」。
引用风格指南规则。 所有🔴和🟡级别的问题都必须说明违反了风格指南的哪个章节。
如果风格指南表述模糊， 标记为🟢 可考虑优化，绝对不要标记为🔴 必须修复。
如果代码符合规范， 直接说明：「未发现违反风格指南的问题，代码符合项目约定。」
不要审查生成的文件（锁文件、构建产物、自动生成的类型定义），重点关注人工编写的源代码。