Back to Details

frontend-code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Frontend Code Review

前端代码审查

Intent

用途

Use this skill whenever the user asks to review frontend code (especially 
.tsx
, 
.ts
, or 
.js
files). Support two review modes:
  1. Pending-change review – inspect staged/working-tree files slated for commit and flag checklist violations before submission.
  2. File-targeted review – review the specific file(s) the user names and report the relevant checklist findings.
Stick to the checklist below for every applicable file and mode.
当用户要求审查前端代码（尤其是
.tsx
、
.ts
或
.js
文件）时，使用此技能。支持两种审查模式：
  1. 待变更审查 – 检查已暂存/工作区中待提交的文件，并在提交前标记违反检查清单的内容。
  2. 指定文件审查 – 审查用户指定的特定文件，并报告相关的检查清单结果。
对于所有适用的文件和模式，请严格遵循以下检查清单。

Checklist

检查清单

See references/code-quality.md, references/performance.md, references/business-logic.md for the living checklist split by category—treat it as the canonical set of rules to follow.
Flag each rule violation with urgency metadata so future reviewers can prioritize fixes.
按分类划分的动态检查清单请参见references/code-quality.md、references/performance.md、references/business-logic.md，请将其视为必须遵循的标准规则集。
为每一项违反规则的内容标记紧急程度元数据，以便后续审查人员可以优先处理修复工作。

Review Process

审查流程

  1. Open the relevant component/module. Gather lines that relate to class names, React Flow hooks, prop memoization, and styling.
  2. For each rule in the review point, note where the code deviates and capture a representative snippet.
  3. Compose the review section per the template below. Group violations first by Urgent flag, then by category order (Code Quality, Performance, Business Logic).
  1. 打开相关组件/模块。收集与类名、React Flow钩子、属性记忆化和样式相关的代码行。
  2. 针对审查要点中的每一条规则，记录代码不符合规则的位置，并截取代表性的代码片段。
  3. 按照以下模板撰写审查部分。首先按紧急标记对违规内容分组，然后按分类顺序（代码质量、性能、业务逻辑）排列。

Required output

要求输出

When invoked, the response must exactly follow one of the two templates:
触发此技能时，回复必须严格遵循以下两个模板之一：

Template A (any findings)

模板A（存在问题时）

undefined
undefined

Code review

Code review

Found <N> urgent issues need to be fixed:
Found <N> urgent issues need to be fixed:

1 <brief description of bug>

1 <brief description of bug>

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

Suggested fix

Suggested fix

<brief description of suggested fix>
... (repeat for each urgent issue) ...
Found <M> suggestions for improvement:
<brief description of suggested fix>
... (repeat for each urgent issue) ...
Found <M> suggestions for improvement:

1 <brief description of suggestion>

1 <brief description of suggestion>

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

Suggested fix

Suggested fix

<brief description of suggested fix>
... (repeat for each suggestion) ...

If there are no urgent issues, omit that section. If there are no suggestions, omit that section.

If the issue number is more than 10, summarize as "10+ urgent issues" or "10+ suggestions" and just output the first 10 issues.

Don't compress the blank lines between sections; keep them as-is for readability.

If you use Template A (i.e., there are issues to fix) and at least one issue requires code changes, append a brief follow-up question after the structured output asking whether the user wants you to apply the suggested fix(es). For example: "Would you like me to use the Suggested fix section to address these issues?"
<brief description of suggested fix>
... (repeat for each suggestion) ...

如果没有紧急问题，请省略该部分。如果没有改进建议，请省略该部分。

如果问题数量超过10个，请汇总为“10+ urgent issues”或“10+ suggestions”，并仅输出前10个问题。

请勿压缩各部分之间的空白行；为了可读性，请保持原样。

如果使用模板A（即存在需要修复的问题）且至少有一个问题需要修改代码，请在结构化输出后附加一个简短的跟进问题，询问用户是否希望你应用建议的修复方案。例如：“是否需要我根据建议的修复方案来解决这些问题？”

Template B (no issues)

模板B（无问题时）

undefined
undefined

Code review

Code review

No issues found.
undefined
No issues found.
undefined