rejudge

Rejudge

每次调用 = 一个评审结果：多位评审者分别调查问题，再由裁决者给出一个答案。想要运行两次？请调用此技能两次。若想获取一个模型给出的单一外部意见，请改用 ask-agent-cli。

根据运行环境选择路径——先看这里

• 在 Pi 内 — 如果 rejudge 工具可用，历史记录、新评审和后续跟进都使用该工具。不要运行 CLI：它会在单独的进程中重新执行整个评审组。调用前，请先按照下方的“查找或继续评审”操作。
• 其他环境（Claude Code 或任何没有 rejudge 工具的宿主环境）——按照下方说明运行 CLI。

如果可用工具中有 rejudge，就使用它。只有在确实未提供该工具时，才回退到 CLI。

查找或继续评审

只要可以获取调用方对话的 ID，就传入该 ID：在工具中使用 conversationId，或在 CLI 中使用 --conversation-id <id>。这是宿主对话 ID，不是 Rejudge 运行 ID。在 Pi shell 工具中，可通过 PI_SESSION_ID 获取；在其他宿主环境中，使用其提供的会话 ID。宿主环境未提供 ID 时，不要自行编造。允许缺少 ID。

如果你已知道本次对话中相关评审的运行 ID，直接使用 resumeRunId 或 --resume <id> 继续。无需查询历史记录。

创建新运行前，请先检查历史记录；即使对话压缩可能已移除之前的运行 ID，也要检查：

• 工具：{ "history": true, "conversationId": "<host-conversation-id>" }，不要提供问题或其他评审输入。
• CLI：rejudge --history --conversation-id <host-conversation-id>。
• 如果无法获取对话 ID，请省略该参数。如果 ID 缺失或没有匹配项，结果会说明原因，并显示当前目录中最近的最多五次运行，不包括同级工作树中的运行。

根据含义进行选择，无需询问用户要选哪次运行：针对被评审代码的后续修改，应继续该评审；独立问题（包括单独的研究任务）应启动新运行。恢复运行失败，不代表可以悄悄从头开始。

强烈不建议从另一个对话继续运行。 这样可能会将独立请求与无关上下文混在一起。请检查返回结果中的对话 ID、日期、标题和问题预览；回退列表有助于发现相关工作，但不能据此自动复用最近一次运行。缺少归属信息不代表某次运行属于当前对话。

查询历史记录不会调用模型，也不需要模型配置。结果最多显示五次运行，按最近一次成功请求排序，并显示匹配总数。超过 2000 个字符的问题会标记为已截断；完整文本仍保存在已保存的运行清单中。

CLI

禁止在沙盒内运行 rejudge CLI，因为沙盒可能无法访问用户已保存的提供商登录信息。

在 Codex 中，必须通过 exec_command 在 TTY 中运行 Rejudge CLI，并通过 write_stdin 保持同一会话连接，直到返回 exit_code；禁止使用 functions.exec 或 functions.wait，也禁止在进程退出前检查结果文件。

rejudge 是已安装的命令，可从任意项目运行。当前目录决定配置查找位置和评审者文件的访问范围。在源代码检出目录中开发 Rejudge 时，首次检出、拉取更新或任何 src/ 发生更改后，都要从该检出目录的根目录运行 just build-cli。

前置条件

• 配置：Rejudge 会从 <cwd> 开始，沿父文件夹向上查找最近的 .rejudge/config.json；如果找不到，则使用 ~/.config/rejudge/config.json（或 $XDG_CONFIG_HOME/rejudge/config.json）。其中包含 reviewers 和 judge 模型 ID。项目配置会覆盖全局配置，因此在信任结果前，请检查 config: <path> 这一行。启用 debugLog: true 后，日志会写入找到的项目配置所在目录旁的 .rejudge/logs/（使用全局配置时则写入 <cwd> 下）。若退出状态非零，请报告 stderr 中的原因；不要猜测模型。
• 密钥：在环境中导出 OPENCODE_API_KEY，或使用 Pi 保存的身份验证信息（pi login）。绝不能将密钥写入代码。缺少密钥不会立即报错——所有 Agent 会在一两分钟后失败，因此长时间运行前请确认身份验证有效。

默认只读

Rejudge 以提问的方式工作：审查者以只读方式运行，只能使用 read/grep/find/ls；裁判只能使用 ask_panel。审查不能修改文件，也不能在被审查的 cwd 中运行 shell 命令。不要传入 --unsafe/--full，它们会为审查者启用写入和 bash 权限。

启动 — 前台阻塞运行（绝不使用 tmux/后台）— 仅限 CLI 路径

（在 Pi 中时，请跳过本节，改为调用 rejudge 工具。）

在前台运行并等待。不要使用 tmux、分离会话、轮询或后台任务。进度会输出到 stderr；审查结果会输出到 stdout。

第 1 步 — 通过带引号的 here-doc 将提示词传入 stdin

CLI 从 stdin 读取提示词——无需临时文件。使用带引号的 here-doc（<<'EOF'），这样内容不会被转义或插值。绝不要通过 $(...)、不带引号的 here-doc 或内联参数传递提示词。从要审查的项目根目录运行（cwd 同时决定配置查找位置和面板 Agent 的工具运行位置）：

# 默认只读——不要添加 --unsafe 或 --full（它们会启用写入和 bash 权限）
rejudge --conversation-id <host-conversation-id> > /tmp/rejudge-<id>.md <<'EOF'
... 完整提示词正文，多行，不要转义 ...
EOF
echo "exit=$?"

后续运行时，在命令中添加 --resume <run-id>。仅当 host ID 不可用时才省略 --conversation-id；恢复运行会保留该运行原有的 conversation ID。

• stdin（here-doc）= 提示词；> /tmp/rejudge-<id>.md 会保存结果。
• stdout（/tmp/rejudge-<id>.md）= 审查结果。
• stderr = 进度和任何错误。
• 退出状态：0 = 成功；任何非零值 = 失败，原因见 stderr。

（提示词若已保存到文件，也可以使用 -f <file>；通过 stdin 输入则无需临时文件。）

一次实际运行需要几分钟（面板以 xhigh 运行），因此请在 bash 命令本身上设置较长的超时时间（超时按每次调用计算）。如果运行因超时被终止，请报告并重新运行；绝不要将其放到后台。

提示词就是任务，而不是 Rejudge 编排指令

Rejudge 已经启动审查者和裁判。提示词会作为任务发送给审查者；其中只能说明该审查者应调查或返回什么。不要要求它启动、调用、询问、验证或协调 Rejudge、面板、审查者、裁判、Agent 或其他审查。这些属于运行时机制，并非任务要求，可能导致审查者尝试嵌套审查。

审查工作时，请使用具体的审查任务：

Identify the two most important risks in the current diff. For each, state the evidence and consequence.

绝不要编写如下提示词：

Ask the panel to verify that reviewers and judge can complete normally.
Ask reviewers to run Rejudge and have the judge collect their results.
Verify the panel, reviewers, or judge.

提示词内容

为 Agent 提供推理所需的信息：

• 用户的目标
• 相关路径／上下文（对于代码审查：指出 git diff 和具体文件）
• 需要回答的确切问题

面向用户的输出（严格要求）

完整的评审答复就是本次运行的结果：在 Pi 中查看 rejudge 工具的结果，或在 CLI 中查看 /tmp/rejudge-<id>.md。除非用户要求，否则不要逐字粘贴。将评审者的措辞转述为通俗语言，并先提供足够的背景，说明评审了什么。如果 Rejudge 回答的是你自己的提示词，请说明你提出了什么问题，以及提供了哪些输入。

请使用以下结构：

### 背景
<1-3 条简洁要点：你向 Rejudge 提出的确切问题、提供的重要文件／差异／数据，以及任何关键假设>

### Rejudge 结果
（仅限 CLI）完整答复见：/tmp/rejudge-<id>.md
<3-7 条简洁要点，用面向用户的通俗语言表达，不要使用原始评审术语，也不要包含长篇引文／差异／日志>

### 总结
<用 1-3 句话说明你自己的解读，以及这会带来什么变化>

### 下一步
<一行，或“无——等待用户指示”>

失败情形

非零退出状态总会在 stderr 中打印原因——请阅读错误消息，不要根据数字推断：

• 配置缺失／无效：告知用户；不要编造模型。
• 未能完成（模型／工具失败）：报告 stderr 的末尾内容；未经确认不要重试。
• 找不到二进制文件：在仓库中构建它（运行 just build-cli），然后重试。
• 因超时被终止：报告此情况并重新运行；可考虑为该仓库使用更轻量的评审组。绝不要在后台运行。