Back to Details

ds-jury

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Get two or three independent reviewers to judge the same change, then fix until they agree.
让两到三位独立的评审者对同一项变更进行评判，然后不断修复直到他们达成一致。

Steps

步骤

  1. Get the work ready first. Answer open PR comments, fix known issues and run the relevant checks. Skip this only if the user wants to throw the code away.
  2. Pick the jurors. Use models the user named. Otherwise pick the strongest available model from two or three different providers, at high reasoning effort.
  3. Find a way to reach them in this harness: team workers or subagents with a model setting, a second agent CLI in the terminal (for example a Codex or Claude CLI), or an API call. If only one model is available, start two or three fresh-context subagents of that model, each with a different persona: correctness, security and edge cases, simplicity and scope.
  4. Write one brief for all jurors: repo path, base SHA, diff command, goal in one sentence, out-of-scope items and check results. Tell them to review only and change nothing.
  5. Ask each juror for: a verdict (APPROVE or CHANGES), a score out of 10 and findings as 
    id severity file:line claim fix
    . Severity is blocker, should or nit.
  6. Run the jurors in parallel. Wait for all of them. A timeout or error is not approval.
  7. Check each finding against the code yourself. Fix the ones you agree with, with the smallest change. Write a one-line reason for each one you reject.
  8. Re-run checks. Start a new round with the same brief, your answers and the new diff.
  9. Report the result. If there is a PR, edit its description and add a table: juror, model, score per round. Write 
    no score
    when a juror gave none. If there is no PR, put the table in your final reply.
  1. 先把准备工作做好。回复尚未处理的 PR 评论，修复已知问题并运行相关检查。只有当用户打算丢弃这段代码时，才可以跳过这一步。
  2. 选择评审者。优先使用用户指定的模型；否则从两到三个不同提供方中挑选最强的可用模型，并设定较高的推理强度（reasoning effort）。
  3. 在当前环境中找到联系他们的方式：使用带模型设置的团队成员（team workers）或子代理（subagents）、在终端中启动第二个 Agent CLI（例如 Codex 或 Claude CLI），或者直接发起 API 调用。如果只有一个可用模型，就启动两到三个使用全新上下文（fresh-context）的该模型子代理，并赋予它们不同的评审视角：正确性、安全性与边缘情况、简洁性与范围控制。
  4. 为所有评审者撰写同一份简报：仓库路径、base SHA、diff 命令、一句话说明目标、范围外（out-of-scope）事项以及检查结果。明确告知他们只做评审，不做任何修改。
  5. 要求每位评审者给出：结论（APPROVE 或 CHANGES）、10 分制评分，以及按 
    id severity file:line claim fix
    格式呈现的发现。严重程度分为 blocker、should、nit。
  6. 并行运行所有评审者，等待全部完成。超时或报错都不算作通过。
  7. 自行核对每条发现与代码是否相符。修复你认可的部分，并采用最小的改动。对每条你拒绝的发现，写下一行理由。
  8. 重新运行检查。开启新一轮，并附上同一份简报、你的答复以及新的 diff。
  9. 汇报结果。如果存在 PR，则编辑其描述并添加一张表格：评审者、模型、各轮评分。若某位评审者未给出评分，写 
    no score
    。如果没有 PR，则把该表格放在你的最终回复中。

Stop when

停止条件

  • Every juror returns APPROVE with no open blocker or should finding.
  • Three rounds are done. Report the open disagreements, with both sides in two lines each. The user decides.
  • A round returns only nits. Stop without another round.
  • 每位评审者都返回 APPROVE，且没有未解决的 blocker 或 should 级别的发现。
  • 已完成三轮。汇报仍然存在的分歧，双方观点各用两行说明。最终由用户决定。
  • 某一轮只返回 nit 级别的问题。不再开启新一轮，直接停止。

Rules

规则

  • Jurors are read-only. They do not edit, push, comment or start their own subagents.
  • Say which jurors are the same model as each other. Do not claim a provider you did not reach.
  • Never invent a score or verdict.
  • Guard the scope. Decline new features and list them as follow-ups.
  • 评审者只读。他们不编辑、不推送、不评论，也不自行启动子代理。
  • 说明哪些评审者使用的是彼此相同的模型。不要声称你并未真正联系到的提供方。
  • 绝不编造评分或结论。
  • 严守范围。拒绝新功能需求，并将其列为后续待办（follow-ups）。