关于 code-reviewer
code-reviewer 是用于审查 Git 变更并处理审查反馈的 skill，面向开发者，强调按范围审查、核实问题后再修复，并记录结论。
主要功能
- 01审查记录的 Git 变更范围
- 02核实反馈后再修复
- 03按严重程度分类问题
- 04记录报告和审查结果
适用场景
- 01完成变更前进行整体审查
- 02评估外部审查者的反馈
- 03修复阻塞性审查问题
- 04中断后恢复审查
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/code-reviewer确认已加载。
附带文件code-reviewer-prompt.md
详细介绍
代码审查员
捆绑运行时
在执行下方的 CLI 命令行之前，将开头的 SSF 替换为 node "<plugin-root>/scripts/spec-superflow.mjs"；<plugin-root> 是本文件上两级目录的绝对路径。切勿直接运行 SSF，也不要调用 PATH 中的 ssf。
有两项职责：审查已记录的 Git 范围，并以严谨的技术态度处理审查发现。按照已持久化的策略进行审查；在实施反馈之前先验证其有效性。
第 1 部分：请求审查
必须：Native final 计划须对整个范围进行一次审查；wave 计划和旧版计划须对每个计划中的波次进行一次审查。对于证据未发生变化的情况，避免重复进行逐任务或最终审查。
可选：遇到阻碍时、重构前，或修复复杂错误后进行审查。
流程
-
从已记录的执行证据中获取审查范围。对于最终审查，按以下顺序确定基准：已记录的
state.review_base起始锚点，然后是已记录隔离上下文中的review_base，最后是目标明确的旧版／手动分支上的git merge-base <target-branch> HEAD；头部使用git rev-parse HEAD。CLI 会验证此完整范围。最终审查失败后，修复期间须保留相同基准；波次修复使用前一波次的头部。切勿改用HEAD~1；它会漏掉多次提交工作中的较早提交。 -
对于 Native
final，当前执行者在本地审查完整差异并编写报告；不要派遣审查员子 Agent。对于经用户授权、采用wave审查的 SDD，每个波次最多派遣一名审查员，使用skills/code-reviewer/code-reviewer-prompt.md。如果无法派遣，则在本地审查。 -
派遣时，只填写
[DESCRIPTION]、[PLAN_OR_REQUIREMENTS]、[BASE_SHA]、[HEAD_SHA]、[WAVE_ID]和[REVIEW_REPORT_FILE]。不要发送整个规划材料包。 -
在
.superpowers/sdd/reviews/<wave-id>.md中写入非空报告，然后使用SSF execution review <change-dir> --wave <wave-id> --base <base-sha> --head <head-sha> --report .superpowers/sdd/reviews/<wave-id>.md --verdict <pass|fail>记录该路径。 对于 schema-2 计划，失败回执还须使用--issue <stable-finding-id>指明正在修复的阻塞缺陷；重试时复用该 ID。其他发现须在报告中保留各自的 ID。相同的失败输入不能再次消耗一次尝试。 -
Critical／Important 级发现须记录为
fail回执，进行有针对性的修复，开展一次有针对性的复审，并以替代的pass回执收尾。Minor 级发现留待之后处理。 -
处于
adjudication-required状态时，等待人工授权后再进行下一次审查。
最小化与范围
对于未提出要求的复杂性，注明缺少的任务要求和差异所在行。 对于会阻碍合并的复杂性，评为 Important；对于安全且不影响行为的冗余，评为 Minor；绝不可仅按行数评定。
第 2 部分：接收审查反馈
响应模式
- 阅读反馈，不要立即回应
- 理解并重述要求
- 根据代码库的实际情况进行验证
- 评估：从本代码库的角度看，技术上是否合理？
- 回应：在技术上认可，或有理有据地提出异议
- 实施：一次处理一项，并逐项测试
严重级别
| 级别 | 含义 | 操作 |
|---|---|---|
| Critical | 错误、安全问题、数据丢失、功能失效 | 立即修复 |
| Important | 架构问题、功能缺失、错误处理不佳、测试缺口 | 开始下一批工作前修复 |
| Minor | 代码风格、优化、文档润色 | 记录待后续处理 |
禁止的回应
切勿：敷衍附和（“你说得对！”、“好建议！”）、未经验证就盲目实施，或感谢审查员。应改为重述要求、提出澄清问题、有理有据地提出异议，或直接修复（行动胜于言辞）。
处理不明确的反馈
仅针对会影响重要决策的不明确发现提问；在范围内继续处理独立且已理解的修复。不要让不明确的可选意见导致全面停工。
特定来源规则
来自用户：可信——理解后再实施。如果范围不明确，仍需询问。不要假意附和。
来自外部审查者：实施前请检查：对该代码库而言是否技术上正确？会破坏现有功能吗？当前实现有何原因？能在所有平台上运行吗？审查者是否了解完整背景？如果建议似乎不妥，应基于技术理由提出异议。
何时提出异议
建议会破坏现有功能、审查者缺乏背景信息、违反 YAGNI、对当前技术栈而言技术上不正确、涉及旧版或兼容性原因，或与用户的架构决策冲突时，应提出异议。用技术理由说明，不要表现得有戒心。
实施顺序
- 仅澄清阻碍修复的实质性不确定事项
- 修复阻塞性问题（故障、安全问题）
- 修复简单问题（拼写错误、导入）
- 修复复杂问题（重构、逻辑）
- 逐项测试每项修复，确认没有回归
常见错误
| 错误 | 修正方法 |
|---|---|
| 假意附和 | 说明要求，或直接采取行动 |
| 盲目实施 | 先对照代码库核实 |
| 批量处理但不测试 | 逐项处理，每项都测试 |
| 未取得波次回执就继续 | 在进入下一个有依赖关系的波次前，通过 SSF execution review 记录 pass/fail |
| 认定审查者一定正确 | 检查是否会造成问题 |
| 回避提出异议 | 技术正确性高于顾虑 |
| 反馈不明确 | 澄清受阻的审查结果，同时继续处理独立的修复事项 |
异常处理
- 解析失败：报告具体文件，并请求重新生成审查包
- 缺少文件：通过
scripts/review-package重新生成。差异为空表示无需审查 - 用户中断：恢复时重新阅读审查报告，从下一批尚未审查的内容继续