ds-review-loop 是一个以「作者 + 新上下文审查者」循环往返为核心的代码审查技能，目标是在同一处改动上让双方逐步收敛到都认为正确，最多四轮。
用途 用于在提交（filing）之前或之后提升改动的正确性，让一个不带历史包袱的审查者持续提出反对意见，直到双方达成一致。
主要流程与能力
- 界定范围：运行 git status --short，不 stash、不丢弃、不包含无关文件；通过 git fetch origin 与 git merge-base HEAD origin/<base branch> 找到基线，每轮使用同一条 diff 命令。
- 写明目标：用两句话写出目标与范围外清单，并先运行覆盖性检查；不发送未通过检查的代码。
- 选择审查者：优先使用更强的模型（可设置模型的子代理、团队工作进程、第二个 CLI），否则使用无历史的全新 DeepSeek 上下文，并记录所选用的是哪一种。
- 发送审查简报：包含仓库路径、基线 sha、diff 命令、目标、范围外清单与检查结果；要求审查者只审查、不编辑/提交/推送/评论/启动子代理，围绕 diff 阅读周边代码，找出缺陷、失效调用方与目标缺口，标出目标不需要的代码，忽略不影响缺陷判断的风格问题。发现按 blocker（目标场景错误）、should（用户会遇到的真实缺陷）、nit（其它）分级，回复以 VERDICT: APPROVE 或 CHANGES 开头，每条发现一行，含编号、级别、文件:行号、结论与修复建议。
- 等待与判断：审查进行期间不修改被审查文件，超时或报错不视为通过；作者逐条判断，同意则做最小修复（优先删除或收窄代码），不同意则附文件:行号与测试输出等证据回复，nit 或范围外事项用一行说明拒绝。
- 维护台账：记录 id、严重度、结果、证据；重跑检查并执行 git diff --shortstat，若 diff 变大则收敛回去。
- 下一轮：发送简报、台账与自上一轮以来的改动，要求审查者只检查未关闭的 id 与变更代码。
停止条件 审查者对当前 diff 返回 APPROVE 且无未关闭的 blocker/should、作者无遗留顾虑；某轮只剩 nit；四轮已完成，或某项在两轮交流后仍有争议——此时用两三行分别陈述双方观点交由用户决定，这种情况不算通过。
规则与限制 同一时间只使用一个审查者；不得为结束循环而随意同意；循环期间不推送，只有在用户要求推送或发布时才在结束后推送；如更新 PR，需注明「Reviewed with ds-review-loop: <N> rounds, <reviewer>, verdict <verdict>」。最终报告轮数、审查者、已修复与已拒绝的发现及理由，以及前后 diff 大小。关于收费、价格与具体平台支持情况，资料未提供。