Back to Details

posting-review-summary

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Posting Review Summary

发布审查总结

When to Use

使用时机

Invoke this skill ONCE per review, AFTER all inline comments are posted. The summary MUST be scannable and brief because engineers read summaries first.
每次审查仅调用该技能一次，且需在所有行内评论发布完成之后。 总结必须简洁易读，因为工程师会优先阅读总结内容。

Context Detection

上下文检测

ContextHow to DetectAction
GitHub Actions
mcp__github_comment__update_claude_comment
available		Update sticky comment
Local reviewTool not available OR explicit local modeWrite to 
review-summary.md
FORBIDDEN: Do not use 
gh pr comment
to create summary comments.
上下文检测方式操作内容
GitHub Actions存在
mcp__github_comment__update_claude_comment
工具		更新固定评论
本地审查无可用工具或明确指定本地模式写入至
review-summary.md
文件
禁止操作： 请勿使用
gh pr comment
创建总结评论。

PR Metadata Assessment

PR元数据评估

If PR title, description, or test plan is genuinely deficient, add as ❓ finding in the Code Review Details collapsible section.
如果PR标题、描述或测试计划确实存在缺陷，请在“代码审查详情”可折叠区域中添加为❓类发现。

Rules

规则

  • DO NOT comment on minor improvements
  • DO NOT comment on adequate-but-imperfect metadata
  • NEVER add as an inline comment
  • DO NOT exceed 3 lines of feedback on the PR Metadata Assessment
  • 请勿对微小改进提出评论
  • 请勿对合格但不够完美的元数据提出评论
  • 绝不添加为行内评论
  • 关于PR元数据评估的反馈内容请勿超过3行

Examples

示例

Genuinely deficient means:
  • Title is literally "fix bug", "update", "changes", or single word
  • Description is empty or just "See Jira"
  • UI changes with zero screenshots
  • No test plan AND changes are testable
Adequate (DO NOT flag):
  • Title describes the change even if imperfect: "Fix login issue for SSO users"
  • Description exists and explains the change, even briefly
  • Test plan references Jira task with testing details
确实存在缺陷的情况包括：
  • 标题仅为“修复bug”、“更新”、“变更”或单个单词
  • 描述为空或仅包含“详见Jira”
  • UI变更但未提供任何截图
  • 无测试计划且变更内容可测试
合格情况（无需标记）：
  • 标题虽不完美但能描述变更内容：“修复SSO用户的登录问题”
  • 描述存在且能简要说明变更内容
  • 测试计划引用了包含测试细节的Jira任务

Format

格式

markdown
- ❓ **QUESTION**: PR title could be more specific
  - Suggested: "Fix null check in UserService.getProfile"
markdown
- ❓ **QUESTION**: PR标题可更具体
  - 建议：“修复UserService.getProfile中的空值检查问题”

Summary Format

总结格式

markdown
**Overall Assessment:** APPROVE / REQUEST CHANGES

[1-2 neutral sentence describing what was reviewed]

<details>
<summary>Code Review Details</summary>

[Findings grouped by severity - see ordering below]

[Optional PR Metadata Assessment - only for truly deficient metadata]

</details>
markdown
**整体评估：** APPROVE / REQUEST CHANGES

[1-2句中立语句描述审查内容]

<details>
<summary>代码审查详情</summary>

[按严重程度分组的发现 - 请遵循以下排序]

[可选PR元数据评估 - 仅针对确实存在缺陷的元数据]

</details>

Findings in Details Section

详情区域中的发现内容

Ordering: Group findings by severity in this exact order:
  1. ❌ CRITICAL (first)
  2. ⚠️ IMPORTANT
  3. ♻️ DEBT
  4. 🎨 SUGGESTED
  5. ❓ QUESTION
Omit empty categories entirely.
Format per finding:
markdown
- [emoji] **[SEVERITY]**: [One-line description]
  - `filename.ts:42`
Example:
markdown
<details>
<summary>Code Review Details</summary>

- ❌ **CRITICAL**: SQL injection in user query builder
  - `src/auth/queries.ts:87`
- ⚠️ **IMPORTANT**: Missing null check on optional config
  - `src/config/loader.ts:23`

</details>
排序规则： 按以下严格的严重程度顺序对发现内容分组：
  1. ❌ CRITICAL（优先级最高）
  2. ⚠️ IMPORTANT
  3. ♻️ DEBT
  4. 🎨 SUGGESTED
  5. ❓ QUESTION
完全省略无内容的分类。
单条发现格式：
markdown
- [表情符号] **[严重程度]**: [一行描述]
  - `filename.ts:42`
示例：
markdown
<details>
<summary>Code Review Details</summary>

- ❌ **CRITICAL**: SQL注入风险存在于用户查询构建器中
  - `src/auth/queries.ts:87`
- ⚠️ **IMPORTANT**: 可选配置缺少空值检查
  - `src/config/loader.ts:23`

</details>

Output Execution

输出执行

GitHub Actions:
Use mcp__github_comment__update_claude_comment to update the sticky comment with the summary.
Local:
Write summary to review-summary.md in working directory.
GitHub Actions环境：
使用mcp__github_comment__update_claude_comment工具更新固定评论，填入总结内容。
本地环境：
将总结内容写入工作目录下的review-summary.md文件。