Back to Details

classifying-review-findings

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Classifying Review Findings

审查结果分类

Severity Categories

严重级别分类

EmojiCategoryCriteria
❌CRITICALWill break, crash, expose data, or violate requirements
⚠️IMPORTANTMissing error handling, unhandled edge cases, could cause bugs
♻️DEBTDuplicates patterns, violates conventions, needs rework within 6 months
🎨SUGGESTEDMeasurably improves security, reduces complexity by 3+, eliminates bug classes
❓QUESTIONRequires human knowledge - unclear requirements, intent, or system conflicts
ALWAYS use hybrid emoji + text format for each finding (if multiple severities apply, use the most severe: ❌ > ⚠️ > ♻️ > 🎨 > ❓):
表情符号分类判定标准
❌CRITICAL会导致程序崩溃、数据泄露或违反需求规范
⚠️IMPORTANT缺少错误处理、未覆盖边缘情况，可能引发缺陷
♻️DEBT存在重复代码模式、违反编码规范，需在6个月内重构
🎨SUGGESTED可显著提升安全性、将复杂度降低3以上、消除某类缺陷
❓QUESTION需要人工确认——需求不明确、意图模糊或存在系统冲突
务必为每个审查结果使用「表情符号+文本」的混合格式（若同时符合多个严重级别，取最高优先级：❌ > ⚠️ > ♻️ > 🎨 > ❓）：

Before Classifying

分类前需确认

Verify ALL three:
  1. Can you trace the execution path showing incorrect behavior?
  2. Is this handled elsewhere (error boundaries, middleware, validators)?
  3. Are you certain about framework behavior and language semantics?
If any answer is "no" or "unsure" → DO NOT classify as a finding.
请验证以下所有三点：
  1. 能否追踪到显示异常行为的执行路径？
  2. 该问题是否已在其他地方处理（如错误边界、中间件、验证器）？
  3. 你是否确定框架行为和语言语义？
若任意问题答案为「否」或「不确定」→ 请勿将其归类为审查问题。

Not Valid Findings (Reject)

无效审查结果（需驳回）

  • Praise ("great implementation")
  • Vague suggestions ("could be simpler")
  • Style preferences without enforced standard
  • Naming nitpicks unless actively misleading
  • PR metadata issues (title, description, test plan) - handled by summary skill, not classified here
  • 表扬类内容（如“实现得很好”）
  • 模糊的建议（如“可以更简单一点”）
  • 无强制标准支撑的风格偏好
  • 除非名称具有误导性，否则不要纠结于命名细节
  • PR元数据问题（标题、描述、测试计划）——由总结类Skill处理，不属于本分类范畴

Suggested Improvements (🎨) Criteria

建议改进（🎨）判定标准

Only suggest improvements that provide measurable value:
  1. Security gain - Eliminates entire vulnerability class (SQL injection, XSS, etc.)
  2. Complexity reduction - Reduces cyclomatic complexity by 3+, eliminates nesting level
  3. Bug prevention - Makes entire category of bugs impossible (type safety, null safety)
  4. Performance gain - Reduces O(n²) to O(n), eliminates N+1 queries (provide evidence)
Provide concrete metrics:
  • ❌ "This could be simpler"
  • ✅ "This has cyclomatic complexity of 12; extracting validation logic would reduce to 6"
If you can't measure the improvement, don't suggest it.
仅建议能带来可衡量价值的改进：
  1. 安全性提升 - 消除某类漏洞（如SQL注入、XSS等）
  2. 复杂度降低 - 将cyclomatic complexity降低3以上、减少嵌套层级
  3. 缺陷预防 - 从根源上避免某类缺陷（如类型安全、空值安全）
  4. 性能优化 - 将时间复杂度从O(n²)降至O(n)、消除N+1查询（需提供依据）
请提供具体指标：
  • ❌ “这个可以更简单”
  • ✅ “这段代码的cyclomatic complexity为12；提取验证逻辑可将其降至6”
若无法衡量改进价值，请勿提出建议。