request-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese请求审查
Request Review
三阶段流程：获取审查结果 → 核实审查结果 → 修复已确认的问题。
Three-phase process: Obtain review results → Verify review results → Fix confirmed issues.
第一阶段：获取审查结果
Phase 1: Obtain Review Results
根据用户输入获取审查结果，有两种来源：
Obtain review results based on user input, with two sources:
来源一：用户直接粘贴
Source 1: User directly pastes
用户直接提供审查文本。
The user provides the review text directly.
来源二：指定编码代理
Source 2: Specify coding agent
用户提供编码代理名称（如 Claude、Cursor、Kimi），则通过 CLI 方式向该代理发送审查请求。
提示词统一为：
使用thermo-nuclear-code-quality-review技能审查未提交更改（只读）各代理的 CLI 命令：
| 代理 | 命令 |
|---|---|
| Claude | |
| Cursor | |
| Kimi | |
若代理不支持 CLI 调用或命令执行失败，告知用户并请求手动粘贴审查结果。
If the user provides a coding agent name (e.g., Claude, Cursor, Kimi), send a review request to the agent via CLI.
The unified prompt is:
Use the thermo-nuclear-code-quality-review skill to review uncommitted changes (read-only)CLI commands for each agent:
| Agent | Command |
|---|---|
| Claude | |
| Cursor | |
| Kimi | |
If the agent does not support CLI invocation or the command execution fails, inform the user and request manual pasting of the review results.
第二阶段：核实审查结果
Phase 2: Verify Review Results
对第一阶段获取的审查结果逐条核实：
- 解析审查文本，识别每个独立问题
- 定位引用的文件；若路径不完整或模糊，则在仓库中搜索
- 对照实际代码验证问题是否成立；标记误报或过时的行号
- 汇总核实结果：哪些成立、哪些为误报，输出简短的核实摘要
Verify each item in the review results obtained in Phase 1:
- Parse the review text and identify each independent issue
- Locate the referenced files; if the path is incomplete or ambiguous, search in the repository
- Verify whether the issue is valid against the actual code; mark false positives or outdated line numbers
- Summarize the verification results: which issues are valid and which are false positives, and output a brief verification summary
第三阶段：修复已确认的问题
Phase 3: Fix Confirmed Issues
仅修复第二阶段确认为成立的问题：
- 除非修复已确认的问题，否则保持行为不变
- 如果问题描述模糊不清，不要猜测；向用户请求澄清
- 最终摘要保持简洁（1-3 句话或简短表格）
Only fix issues confirmed as valid in Phase 2:
- Keep behavior unchanged unless fixing confirmed issues
- Do not guess if the issue description is ambiguous; request clarification from the user
- Keep the final summary concise (1-3 sentences or a short table)
输出格式
Output Format
所有修复完成后，输出包含两个部分的结构化报告：
After all fixes are completed, output a structured report containing two sections:
已修复
Fixed
列出每个已成功解决的问题，每条必须包含：
- 问题摘要
- 所做变更（一句话）
- 文件路径和行号
List each successfully resolved issue, each entry must include:
- Issue summary
- Changes made (one sentence)
- File path and line number
未修复
Unfixed
列出每个未修复的问题，每条必须包含合理的理由，例如：
- 误报：对照代码验证，该问题不存在或已处理（引用具体证据）
- 风险过高：修复可能引入回归或破坏现有行为（描述具体风险）
- 超出范围：需要架构变更或跨模块协调（描述涉及范围）
- 信息不足：缺少安全修复所需的上下文或权限（说明缺少什么）
- 设计冲突：所提议的修复与有意为之的设计决策相矛盾（引用具体决策）
"已跳过"或"未处理"等模糊理由不可接受。每条未修复项都必须包含充分的理由，使用户能够判断该决定是否合理。
List each unfixed issue, each entry must include a valid reason, for example:
- False Positive: Verified against code, the issue does not exist or has been addressed (cite specific evidence)
- High Risk: Fix may introduce regression or break existing behavior (describe specific risks)
- Out of Scope: Requires architectural changes or cross-module coordination (describe the scope involved)
- Insufficient Information: Lacks context or permissions required for security fixes (specify what is missing)
- Design Conflict: The proposed fix contradicts intentional design decisions (cite specific decisions)
Vague reasons such as "Skipped" or "Not processed" are unacceptable. Each unfixed entry must include sufficient reasoning to enable the user to judge whether the decision is reasonable.