状态稳定
类型原子 Skill
领域软件测试
生命周期测试设计
适合角色QA / DEV
语言中文 / 英文
评测有评测 ✓
同步日期2026-09-15
解决什么问题
它把当前 Skill 的方法整理成可以直接执行、评审和复用的质量输入。
- 风险驱动：优先线上故障、资损、安全与核心可维护性；不做命名/缩进类噪声清单。
- 证据导向：每条发现尽量给出文件路径、行号或代码片段，并说明触发路径与后果。
- 双门槛：必须同时有可识别代码版本（如仓库 + PR / 提交 / 分支 / 标签 / 修订号）和可审查变更（如 Diff / Patch、变更文件内容或可访问的 base→head 范围）。代码身份、变更内容与角色报告不能互相替代。
- 不要把代码片段或角色报告当成代码版本，也不要把 PR / 提交号当成已提供 Diff；双门槛缺一就阻塞。
适用场景
推荐使用
- 需要审查 PR / Diff / 提交，拦截合入前的逻辑、安全、资损与可维护性风险。
- 需要按 P0/P1/P2 分级、带定位与可落地修复建议的审查报告。
- 需要从 QA / 工程质量视角补充开发自审未覆盖的风险点。
常见误区
- 不要把代码片段或角色报告当成代码版本，也不要把 PR / 提交号当成已提供 Diff；双门槛缺一就阻塞。
- 不要因为产品或 UI/UX 报告存在就自动启用其关注点；先判断本次变更是否相关，并保留来源。
- 不要把所有项写成同等重要，或堆砌风格类低价值意见。
- 不要跳过假设与信息缺口。
- 不要对未在本次变更范围内的存量逻辑强制重构。
输入
最低输入
- 当前任务范围、目标和待处理对象。
推荐输入
- 产出前必须阅读并遵循 prompts/code-review.md（最低覆盖清单、输出结构、质量要求）。
- 需要 Excel/CSV/JSON/Word 等格式时：读 output-formats.md，并按用户格式要求输出。
- 需要套用现成模板时：读 output-templates/ 中匹配的模板，不要自创冲突结构。
- 需要审查维度细化或分级细则时：读 references/review-dimensions.md。
可选上下文
- 用户要示例或对标现有资产时：读 examples/ 中相关样例。
- 需要格式转换或辅助校验时：优先使用 scripts/ 中已有脚本，而不是重写一遍。
- 用户只要最短上手路径时：读 quick-start.md。
- 需要评测/回归本 skill 时：使用 evals/，并用 skill-up 校验与运行。
输出
输出会围绕该 Skill 的方法形成可执行结果，并明确事实、假设、风险和下一步。
不安装也能判断输出价值
- 01已遵循主提示词的输出结构
- 02已确认代码身份与可审查变更两个门槛；若阻塞，未输出完成态审查或合并建议
- 03最低覆盖关注：变更摘要、综合风险评级、P0/P1/P2 清单、可测性与可观测性、API/契约兼容、修复优先级、剩余风险与假设…（细节以主提示词为准）
- 04已覆盖最低清单，或标明为何省略
查看完整输出结构
- 05高风险项有明确 P0/P1 分级与依据
- 06未编造用户未提供的细节
- 07假设与信息缺口已标明
工作原理
- 01阅读并遵循「按需加载」中的主提示词（覆盖清单、输出结构、质量要求）。
- 02开始审查前同时确认：可识别的代码版本，以及对应的可审查变更；缺任一项都输出阻塞结果并索要准确材料。
- 03只补充真正影响结果的项目上下文：变更范围、业务目标、技术栈、上下游依赖、已知风险、团队规范。
- 04可选角色报告仅作为带来源的补充上下文；产品和 UI/UX 报告只在本次变更涉及其关注范围时使用。
- 05默认 Markdown；用户指定其他格式时再切换。
安装与快速开始
安装命令 / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/code-review
-gcode-review.prompt
@skill code-review
结合当前项目上下文，按该 Skill 的要求给出可执行结果。
补充上下文：
[粘贴项目背景或需求]---
name: code-review
description: Use this skill when you need a risk-driven code review of a PR/diff with severity-ranked findings and actionable fixes; triggers include 代码审查, 代码评审, code review, and PR review.
---
# 代码审查（中文版）
**英文版：** 见对应英文技能。
## 何时使用
- 需要审查 PR / Diff / 提交，拦截合入前的逻辑、安全、资损与可维护性风险。
- 需要按 P0/P1/P2 分级、带定位与可落地修复建议的审查报告。
- 需要从 QA / 工程质量视角补充开发自审未覆盖的风险点。
## 执行流程
1. 阅读并遵循「按需加载」中的主提示词（覆盖清单、输出结构、质量要求）。
2. 开始审查前同时确认：可识别的代码版本，以及对应的可审查变更；缺任一项都输出阻塞结果并索要准确材料。
3. 只补充真正影响结果的项目上下文：变更范围、业务目标、技术栈、上下游依赖、已知风险、团队规范。
4. 可选角色报告仅作为带来源的补充上下文；产品和 UI/UX 报告只在本次变更涉及其关注范围时使用。
5. 默认 Markdown；用户指定其他格式时再切换。
## 核心约束
- 风险驱动：优先线上故障、资损、安全与核心可维护性；不做命名/缩进类噪声清单。
- 证据导向：每条发现尽量给出文件路径、行号或代码片段，并说明触发路径与后果。
- 双门槛：必须同时有可识别代码版本（如仓库 + PR / 提交 / 分支 / 标签 / 修订号）和可审查变更（如 Diff / Patch、变更文件内容或可访问的 base→head 范围）。代码身份、变更内容与角色报告不能互相替代。
- 缺任一门槛时明确输出 `status: blocked`，区分 `missing_code_identity` 与 `missing_reviewable_change`；不得声称审查完成、给出合并建议或虚构代码发现。
- 角色报告是可选输入；使用其中内容时保留 `source_role`。产品报告仅补充业务规则、状态流或验收语义，UI/UX 报告仅补充界面状态、反馈、响应式或可访问性关注点，不得把角色观点当成代码事实。
- 严格分级：P0 阻塞合入、P1 建议本迭代修复、P2 可纳入技术债。
- 把「已确认事实」和「当前假设」分开写；不要编造用户未提供的接口、字段、环境或根因。
- 对事不对人；尊重现有技术栈，未经授权不要求换框架/推翻架构。
- 结果必须可执行：每条问题有修复方向或修改前后示例。
## 按需加载
- 产出前必须阅读并遵循 `prompts/code-review.md`（最低覆盖清单、输出结构、质量要求）。
- 需要 Excel/CSV/JSON/Word 等格式时：读 `output-formats.md`，并按用户格式要求输出。
- 需要套用现成模板时：读 `output-templates/` 中匹配的模板，不要自创冲突结构。
- 需要审查维度细化或分级细则时：读 `references/review-dimensions.md`。
- 用户要示例或对标现有资产时：读 `examples/` 中相关样例。
- 需要格式转换或辅助校验时：优先使用 `scripts/` 中已有脚本，而不是重写一遍。
- 用户只要最短上手路径时：读 `quick-start.md`。
- 需要评测/回归本 skill 时：使用 `evals/`，并用 skill-up 校验与运行。
## 交付前自检
- [ ] 已遵循主提示词的输出结构
- [ ] 已确认代码身份与可审查变更两个门槛；若阻塞，未输出完成态审查或合并建议
- [ ] 最低覆盖关注：变更摘要、综合风险评级、P0/P1/P2 清单、可测性与可观测性、API/契约兼容、修复优先级、剩余风险与假设…（细节以主提示词为准）
- [ ] 已覆盖最低清单，或标明为何省略
- [ ] 高风险项有明确 P0/P1 分级与依据
- [ ] 未编造用户未提供的细节
- [ ] 假设与信息缺口已标明
## 常见误区
- 不要把代码片段或角色报告当成代码版本，也不要把 PR / 提交号当成已提供 Diff；双门槛缺一就阻塞。
- 不要因为产品或 UI/UX 报告存在就自动启用其关注点；先判断本次变更是否相关，并保留来源。
- 不要把所有项写成同等重要，或堆砌风格类低价值意见。
- 不要跳过假设与信息缺口。
- 不要对未在本次变更范围内的存量逻辑强制重构。
- 不要输出大段与当前变更无关的空泛理论。