关于 review-loop
review-loop 是面向开发团队的代码审查技能，要求修复内容也经过独立审查。它规定了有轮次上限的审查与修复流程、仓库检查和最终报告。
主要功能
- 01每轮由新的子 Agent 审查
- 02首轮征求第二意见
- 03按严重程度决定修复项
- 04修复后运行仓库检查
- 05最多五轮并设停止规则
- 06提交与报告指引
适用场景
- 01审查代码变更及其修复
- 02对差异进行定向复审
- 03将审查限制在规定轮次内
- 04汇报跳过项和未解决发现
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/review-loop确认已加载。
详细介绍
Review Loop
持续审查、修复并再次审查，直到某一轮发现没有值得修复的问题。修复属于新代码，因此也需要单独审查。
规则
-
每轮都在全新的子 Agent 中审查。 使用
<target> --sub调用review-code（默认目标为diff）。如果没有review-code，则启动子 Agent，检查正确性、安全性、资源使用和性能方面的缺陷，并针对每项发现评定其是否值得修复：Yes / Judgment call / No。绝不要在当前审查中自行审查自己的修复。 -
仅在第 1 轮传入
--second-opinion。 第 1 轮审查完整变更；后续各轮审查小范围的修复差异，再请另一个 Agent 审查会增加成本，却只能带来很少的覆盖。它的 Final Call 会在任何修复之前读取代码，因此不会违反规则 1。 -
从第 2 轮开始，所有目标（包括路径）都使用
diff。 GitHub 看不到尚未推送的修复；重新审查整个代码库会浪费上下文；限定路径的审查可能会漏掉相关文件中的修复。对于pr <number>，先检出该 PR。 -
修复所有 Yes；对于 Judgment call，仅当问题属于 Trivial 或 Small 时才修复。 跳过 No。如果某轮有 Final Call，则按其结论处理：Fix → 修复，Optional → 仅在问题属于 Trivial 或 Small 时修复，Skip → 跳过。之后的轮次再次提出已跳过的问题时，不要重新修复或重新争论。
-
每轮修复后运行仓库的检查（
make build/make test/make lint；如果没有这些命令，则运行原生命令）。在下一轮审查前修复导致的故障。 -
当某一轮没有需要修复的新问题时停止。 最多进行 5 轮；第 5 轮仅审查，即使发现可处理的问题也不得修复。该轮审查后不要再修改代码；将未解决的问题交给用户。如果已修复的问题在任意一轮再次出现，则停止修复并报告未解决的问题。
-
除非另有说明，否则每项修复都要提交。
--commit each（默认值）表示每项已修复问题单独提交一次；--commit end表示循环结束后提交一次。绝不推送。在默认分支上，首次提交前先创建分支；否则diff会以 HEAD 为基准，已提交的修复将不会出现在下一轮审查中。 -
最后报告： 运行的轮数及停止原因、修复内容（
path:line— 改动说明）、跳过的问题及各自的原因、未解决的问题，以及检查结果。