Back to Details

review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Building is not done when the code runs. It is done when the code is correct.
AI moves fast. Fast means things get built that work on the surface but drift from the architecture, violate the design system, or miss edge cases that matter. This skill catches those things before they compound into bigger problems.
Run this after every feature. Before you move on.
代码能运行并不代表开发完成，只有代码正确才算完成。
AI的发展速度很快。快速意味着有些功能表面上能正常工作，但却偏离了架构、违反了设计系统，或者遗漏了关键的边缘情况。该Skill能在这些问题演变为更大的麻烦之前将其发现。
在完成每个功能后都运行该Skill，再进入下一阶段。

What This Skill Does Not Do

该Skill不具备以下功能

It does not fix anything. It reports what it finds and lets the developer decide what matters and what to do about it. Fixing without understanding is how problems get buried, not solved.
它不会修复任何问题。它只会报告发现的问题，由开发者决定哪些问题重要以及如何处理。不理解问题就直接修复只会埋下隐患，而非解决问题。

Step 1 — Understand What Should Have Been Built

步骤1 — 明确应实现的内容

Before reviewing anything, establish the benchmark.
Read in this order:
  • The implementation plan from 
    /architect
    if one exists
  • The feature description or task that was given
  • Any relevant context files — architecture boundaries, code standards, design rules
If no plan exists, ask the developer to describe what the feature was supposed to do before reviewing. You cannot verify correctness without knowing what correct looks like.
在开始评审之前，先确立基准。
按以下顺序阅读：
  • 若存在
    /architect
    中的实现方案，优先阅读
  • 给定的功能描述或任务要求
  • 任何相关的上下文文件——架构边界、代码标准、设计规则
如果没有方案，请开发者在评审前描述该功能的预期用途。不知道“正确”的标准，就无法验证正确性。

Step 2 — Review in Three Layers

步骤2 — 三层评审

Layer 1 — Does it match the plan?

第一层 — 是否符合规划？

Compare what was built against what was planned.
Check:
  • Every part of the feature description — is it all there?
  • The decisions made during planning — are they reflected in the code?
  • The scope — did the implementation stay within bounds or add things that were not asked for?
Flag anything that was planned but missing. Flag anything that was built but not planned.
将已实现的内容与规划内容进行对比。
检查：
  • 功能描述的每一部分是否都已实现？
  • 规划阶段做出的决策是否在代码中有所体现？
  • 范围是否符合要求？是否添加了未要求的内容？
标记所有已规划但未实现的内容，以及所有已实现但未规划的内容。

Layer 2 — Does it respect the system?

第二层 — 是否遵循系统规范？

This is where AI drift most commonly happens. The feature works, but it violates rules that the project depends on.
Check:
  • Architecture boundaries — does code in the right place own the right responsibilities? No UI logic in API routes. No DB calls in components. Whatever the project's boundaries are — are they respected?
  • Design system — are the correct tokens, classes, and patterns used? Any hardcoded values that should be variables? Any raw color classes that should use the design system?
  • Code standards — naming conventions, file organisation, TypeScript strictness, error handling patterns — do they match what the project established?
  • Existing patterns — does this feature introduce a new pattern when an existing one should have been used?
这是AI最容易出现偏差的地方。功能能正常工作，但却违反了项目依赖的规则。
检查：
  • 架构边界——代码是否位于正确的位置并承担正确的职责？API路由中是否包含UI逻辑？组件中是否存在数据库调用？无论项目的边界是什么，是否都得到了遵守？
  • 设计系统——是否使用了正确的标记、类和模式？是否存在应使用变量的硬编码值？是否存在应使用设计系统的原始颜色类？
  • 代码标准——命名规范、文件组织、TypeScript严格性、错误处理模式是否符合项目既定要求？
  • 现有模式——当已有模式可用时，该功能是否引入了新的模式？

Layer 3 — Is it production ready?

第三层 — 是否已准备好投入生产？

Check:
  • Error handling — what happens when things go wrong? Are errors caught and handled or does the feature silently fail?
  • Edge cases — empty states, loading states, missing data — are these handled?
  • Console errors — any errors or warnings in the browser or terminal?
  • Obvious bugs — anything that would clearly break for a real user?
检查：
  • 错误处理——出现问题时会发生什么？错误是否被捕获并处理，还是功能会静默失败？
  • 边缘情况——空状态、加载状态、缺失数据是否都已处理？
  • 控制台错误——浏览器或终端中是否存在任何错误或警告？
  • 明显的bug——是否存在会导致真实用户使用时崩溃的问题？

Step 3 — Report What You Found

步骤3 — 报告发现的问题

After completing all three layers, produce a clear report. Do not bury issues. Do not soften them. Report honestly so the developer can make informed decisions.
undefined
完成所有三层评审后，生成清晰的报告。不要掩盖问题，不要弱化问题。如实报告，以便开发者做出明智的决策。
undefined

Review — [Feature Name]

评审 — [功能名称]

Layer 1 — Plan alignment

第一层 — 规划一致性

[PASS / ISSUES FOUND] [List any gaps between what was planned and what was built]
[通过 / 发现问题] [列出规划内容与已实现内容之间的所有差异]

Layer 2 — System integrity

第二层 — 系统完整性

[PASS / ISSUES FOUND] [List any architecture, design, or code standard violations]
[通过 / 发现问题] [列出所有架构、设计或代码标准违规情况]

Layer 3 — Production readiness

第三层 — 生产就绪性

[PASS / ISSUES FOUND] [List any error handling gaps, edge cases, or obvious bugs]
[通过 / 发现问题] [列出所有错误处理漏洞、边缘情况或明显的bug]

Summary

总结

[X] issues found across [Y] layers.
[If no issues: "No issues found. This feature is ready to ship."] [If issues: "Resolve the above before moving to the next feature."]

---
共在[Y]个层面发现[X]个问题。
[若无问题：“未发现问题。该功能已准备好发布。”] [若有问题：“解决上述问题后再进入下一个功能的开发。”]

---

Step 4 — Let the Developer Decide

步骤4 — 由开发者决定

After presenting the report, stop. Do not start fixing. Do not suggest fixes unless the developer asks.
Wait for the developer to:
  • Ask you to fix a specific issue
  • Tell you an issue is intentional and can be ignored
  • Confirm everything is resolved and ready to move on
The developer owns the quality decision. You inform it.
提交报告后停止操作。不要开始修复问题。除非开发者要求，否则不要提出修复建议。
等待开发者：
  • 要求你修复特定问题
  • 告知你某一问题是有意为之，可以忽略
  • 确认所有问题都已解决，可以进入下一阶段
开发者拥有质量决策的最终决定权，你只负责提供信息。

Severity Guide

严重程度指南

Not all issues are equal. Use this to help the developer prioritise:
Critical — fix before moving on
  • Architecture boundary violations that will break future features
  • Missing error handling that causes silent failures
  • Functionality that was planned but completely missing
Important — fix soon
  • Design system drift that will cause UI inconsistency
  • Code standard violations that will compound across the codebase
  • Edge cases that a real user will encounter
Minor — fix when convenient
  • Naming inconsistencies that do not affect behaviour
  • Missing optimisations
  • Style issues that do not affect the design system
Label each issue with its severity so the developer can triage quickly.
并非所有问题的严重程度都相同。使用以下指南帮助开发者确定优先级：
关键问题 — 必须修复后才能继续
  • 会破坏未来功能的架构边界违规
  • 导致静默失败的缺失错误处理
  • 已规划但完全未实现的功能
重要问题 — 尽快修复
  • 会导致UI不一致的设计系统偏差
  • 会在整个代码库中蔓延的代码标准违规
  • 真实用户会遇到的边缘情况
次要问题 — 方便时修复
  • 不影响功能的命名不一致
  • 缺失的优化
  • 不影响设计系统的样式问题
为每个问题标记严重程度，以便开发者快速分类处理。

The Standard

标准

The question this skill answers is not "does it work?"
The question is "is it correct?"
Working and correct are not the same thing. A feature can work today and break the project tomorrow. Review exists to catch the difference.
该Skill要回答的问题不是“它能运行吗？”
而是“它是否正确？”
能运行和正确是两回事。一个功能今天能运行，但明天可能会破坏整个项目。评审的目的就是发现这种差异。