Back to Details

ds-review-loop

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Make a change more correct by letting one fresh reviewer push back until you both agree.
通过让一位使用全新上下文的审查者不断提出异议，直到双方达成一致，使变更更加正确。

Steps

步骤

  1. Scope the change. Run 
    git status --short
    . Do not stash, discard or include unrelated files. Find the base: 
    git fetch origin
    , then 
    git merge-base HEAD origin/<base branch>
    . Use one diff command for every round.
  2. Write the goal and out-of-scope list in two sentences. Run the covering checks. Do not send code that fails them.
  3. Pick the reviewer: a stronger model if the harness can reach one (subagent with a model setting, team worker, second CLI), or else a fresh DeepSeek context with no history. Record which one.
  4. Send this brief:
    Review only. Do not edit, commit, push, comment or start subagents.
Repo: <path>  Base: <sha>  Diff: git diff <sha> [-- <paths>]
Goal: <goal>  Out of scope: <list>  Checks: <results>
Read the code around the diff. Find bugs, broken callers and gaps against the goal.
Flag code the goal does not need. Ignore style unless it hides a bug.
blocker = goal case is wrong. should = real bug users will hit. nit = anything else.
Reply: VERDICT: APPROVE or CHANGES, then one line per finding:
R1 [blocker|should|nit] file:line claim. Fix: suggestion
  5. Wait for the reply. Do not edit the scoped files while the review runs. A timeout or error is not approval.
  6. Judge each finding yourself. Agree: make the smallest fix, preferring to delete or narrow code. Disagree: reply with evidence (file:line, test output). Nit or out of scope: decline in one line.
  7. Keep a ledger: id, severity, outcome, evidence. Re-run checks and 
    git diff --shortstat
    . If the diff grew, cut it back.
  8. For the next round send the brief, the ledger and the changes since the last round. Ask the reviewer to check only open ids and changed code.
  1. 限定变更范围。运行 
    git status --short
    。不要 stash、discard，也不要包含无关文件。确定基线：运行 
    git fetch origin
    ，然后运行 
    git merge-base HEAD origin/<base branch>
    。每一轮只使用一个 diff 命令。
  2. 用两句话写明目标和范围外事项。运行相关检查。不要发送未通过检查的代码。
  3. 选择审查者：如果 harness 能调用更强的模型，就使用该模型（可指定模型的 subagent、team worker、第二个 CLI）；否则使用无历史记录的新 DeepSeek 上下文。记录使用的是哪一种。
  4. 发送以下审查说明：
    仅审查。不要编辑、提交、推送、评论或启动 subagent。
仓库：<path>  基线：<sha>  差异：git diff <sha> [-- <paths>]
目标：<goal>  范围外：<list>  检查：<results>
阅读差异周围的代码。找出 bug、失效的调用方以及未达到目标之处。
标出目标不需要的代码。除非代码风格会掩盖 bug，否则忽略风格问题。
blocker = 目标场景不正确。should = 用户会遇到的真实 bug。nit = 其他问题。
回复：VERDICT: APPROVE 或 CHANGES，然后每项发现各占一行：
R1 [blocker|should|nit] file:line 问题。修复：建议
  5. 等待回复。审查进行时不要编辑范围内的文件。超时或错误不等于批准。
  6. 自行判断每项发现。如果同意：进行最小幅度的修复，优先删除代码或收窄代码范围。如果不同意：附上证据回复（file:line、测试输出）。如果是 nit 或超出范围：只用一行说明并拒绝该发现。
  7. 维护一份审查台账，记录 id、严重程度、处置结果和证据。重新运行检查以及 
    git diff --shortstat
    。如果差异量增加，就把它缩减回去。
  8. 对于下一轮，发送上述审查说明、台账以及自上一轮以来的变更。请审查者只检查尚未关闭的 id 和发生变更的代码。

Stop when

停止条件

  • The reviewer returns APPROVE on the current diff, no blocker or should is open, and you have no concern left.
  • A round returns only nits.
  • Four rounds are done, or one item stays disputed after two exchanges. Report both sides in two or three lines each and let the user decide. This is not approval.
  • 审查者对当前差异返回 APPROVE，没有尚未解决的 blocker 或 should，且你已没有其他疑虑。
  • 某一轮只返回 nits。
  • 已完成四轮，或某一项在两轮交换后仍有争议。用两三行报告双方观点，并让用户决定。这不视为批准。

Rules

规则

  • One reviewer at a time. Never agree just to end the loop.
  • Do not push during the loop. Push afterward only if the user asked to push or ship.
  • If you update a PR, add: 
    Reviewed with ds-review-loop: <N> rounds, <reviewer>, verdict <verdict>.
  • Report rounds, reviewer, fixed and declined findings with reasons, and diff size before and after.
  • 每次只使用一名审查者。绝不要为了结束循环而同意。
  • 循环期间不要 push。只有用户要求 push 或 ship 时，循环结束后再 push。
  • 如果要更新 PR，请添加：
    Reviewed with ds-review-loop: <N> rounds, <reviewer>, verdict <verdict>.
  • 报告循环轮数、审查者、已修复和已拒绝的发现及理由，以及前后的差异规模。