Rejudge

Rejudge

One invocation = one review result: separate reviewers investigate the question and a judge returns one answer. Want two runs? Invoke the skill twice. For one external opinion from one model, use ask-subagent instead.

Pick the path by where you're running — THIS FIRST

• Inside Pi — if the rejudge tool is available, call that tool with the question and any output instructions. Do not run the CLI: it would repeat the whole panel in a separate process. Skip straight to "Output to the user".
• Anywhere else (Claude Code or any harness without the rejudge tool) — run the CLI as described below.

If rejudge appears in the available tools, use it. Fall back to the CLI only when the tool genuinely is not exposed.

The CLI

MUST NOT run the rejudge CLI inside a sandbox because the sandbox can hide the user’s saved provider login.

In Codex, MUST run the Rejudge CLI with exec_command in a TTY and keep the same session attached through write_stdin until it returns an exit_code; MUST NOT use functions.exec or functions.wait, and MUST NOT inspect the result file before the process exits.

rejudge is the installed command and runs from any project. The current directory controls config lookup and reviewer file access. When developing Rejudge from a source checkout, run just build-cli from that checkout's root after a fresh checkout, a pull, or any src/ change.

Prerequisites

• Config: Rejudge reads <cwd>/.rejudge/config.json, else ~/.config/rejudge/config.json (or $XDG_CONFIG_HOME/rejudge/config.json). It contains reviewers and judge model IDs. A project config shadows the global config, so check the config: <path> line before trusting the result. With debugLog: true, logs go under .rejudge/logs/. On a non-zero exit, report the stderr reason; do not guess models.
• Key: OPENCODE_API_KEY exported in the environment, or Pi's stored auth (pi login). Never baked in. A missing key isn't instant — all agents fail a minute or two in, so confirm auth before a long run.

Read-only by default

Rejudge is an ask: reviewers run read-only with read/grep/find/ls, and the judge gets only ask_panel. A review cannot modify files or run shell commands in the reviewed cwd. Do not pass --unsafe/--full; they enable write/bash for reviewers.

Launch — foreground, blocking (never tmux/background) — CLI path only

(Skip this whole section when inside Pi — call the rejudge tool instead.)

Run it in the foreground and wait. No tmux, detached sessions, polling, or background jobs. Progress streams to stderr; the review result goes to stdout.

Step 1 — feed the prompt on stdin via a quoted heredoc

The CLI reads the prompt from stdin — no temp file. Use a quoted heredoc (<<'EOF') so nothing is escaped or interpolated. Never pass the prompt via $(...), an unquoted heredoc, or an inline argument. Run it from the project root you want reviewed (the cwd drives BOTH config lookup and the panel agents' tools):

# read-only by default — do NOT add --unsafe or --full (those enable write/bash)
rejudge > /tmp/rejudge-<id>.md <<'EOF'
... full prompt body, multi-line, no escaping ...
EOF
echo "exit=$?"

• stdin (the heredoc) = the prompt; > /tmp/rejudge-<id>.md captures the result.
• stdout (/tmp/rejudge-<id>.md) = the review result.
• stderr = progress and any error.
• Exit status: 0 = success; any non-zero = failure, with the reason on stderr.

(A prompt already sitting in a file still works with -f <file>; stdin is the no-temp-file path.)

A real run is minutes (the panel runs at xhigh), so set a generous timeout on the bash command itself (the timeout is per-invocation). If a run is killed for time, report it and re-run; never background it.

The prompt is the task, not Rejudge orchestration

Rejudge already starts the reviewers and judge. The prompt is delivered to a reviewer as its task; it must say only what that reviewer should investigate or return. Do not ask it to start, call, ask, verify, or coordinate Rejudge, a panel, reviewers, a judge, agents, or another review. Those are runtime mechanics, not task requirements, and can make a reviewer attempt a nested review.

Use a concrete review task when reviewing work:

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

Never write prompts such as:

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.

Prompt content

Give the agents what to reason about:

• the user's goal
• relevant paths / context (for a code review: point at git diff and the specific files)
• the exact question to answer

Output to the user (strict)

The full review answer is the run's result — the rejudge tool result inside Pi, or /tmp/rejudge-<id>.md from the CLI. Do not paste it verbatim unless asked. Translate reviewer wording into plain language and first give enough context to understand what was reviewed. If Rejudge answered your own prompt, state what you asked and what inputs you provided.

Use this structure:

### Context
<1-3 concise bullets: the exact question you asked Rejudge, the important files/diff/data you provided, and any key assumption>

### Rejudge result
(CLI only) Full answer in: /tmp/rejudge-<id>.md
<3-7 concise bullets in plain user-facing language, no raw reviewer jargon, no long quotes/diffs/logs>

### Summary
<your own 1-3 sentence interpretation and what it changes>

### Next action
<one line, or "none — waiting for user direction">

Failure modes

A non-zero exit always prints why on stderr — read the message, don't decode the number:

• config missing/invalid: tell the user; don't invent models.
• didn't complete (a model/tool failed): report the stderr tail; don't retry without confirmation.
• bin missing: build it (just build-cli in the repo), then retry.
• killed for time: report and re-run; consider a lighter panel for that repo. Never background.