ds-jury

找两到三位独立评审者审查同一项更改，然后持续修复，直到他们达成一致。

步骤

1. 先做好准备工作。回复未处理的 PR 评论，修复已知问题并运行相关检查。只有在用户想要丢弃代码时才跳过此步骤。
2. 选定评审者。使用用户指定的模型。否则，从两个或三个不同提供商中选择能力最强的模型，并使用高推理强度。
3. 在当前环境中找到联系他们的方式：使用可设置模型的团队工作者或子 Agent、在终端中运行第二个 Agent CLI（例如 Codex 或 Claude CLI），或调用 API。如果只有一个模型可用，则启动两个或三个使用该模型、拥有独立上下文的子 Agent，并为每个子 Agent 指定不同的角色：正确性、安全性与边缘情况、简洁性与范围。
4. 为所有评审者编写一份简要说明：仓库路径、基础 SHA、差异命令、一句话说明目标、范围外事项以及检查结果。请他们只做审查，不要进行任何更改。
5. 请每位评审者提供：结论（APPROVE 或 CHANGES）、10 分制评分，以及格式为 id severity file:line claim fix 的问题。严重程度为 blocker、should 或 nit。
6. 并行运行评审者。等待所有评审者完成。超时或出错不算批准。
7. 逐项核实每个问题。对你认可的问题做最小改动修复。对每个驳回的问题写一句理由。
8. 重新运行检查。使用相同的简要说明、你的答复和新的差异，开始新一轮审查。
9. 报告结果。如果有 PR，则编辑其描述并添加一个表格，列出评审者、模型以及每轮评分。如果评审者未评分，则填写 no score。如果没有 PR，则在最终回复中提供该表格。

停止条件

• 每位评审者都给出 APPROVE，且没有未解决的 blocker 或 should 问题。
• 已完成三轮。报告尚未解决的分歧，每一方用两行说明。由用户决定。
• 某轮只剩 nit。无需再进行下一轮，直接停止。

规则

• 评审者只能只读审查。他们不得编辑、推送、发表评论或启动自己的子 Agent。
• 说明哪些评审者使用的是同一模型。不要声称联系过实际上未联系的提供商。
• 不得编造评分或结论。
• 严格控制范围。拒绝新增功能，并将其列为后续事项。