rejudge-diff

Rejudge Diff

Rejudge によるコードレビュー — diff を指定して /rejudge を実行します。まず rejudge スキルを読んでください。Pi 内では rejudge ツールを呼び出し、ツールが公開されていない場合にのみ CLI を使用してください。このスキルがレビューのプロンプトと表示方法を管理します。パネルは読み取り専用で実行され、git_diff を通じて diff を取得します。

一般的な複数モデルへの質問には rejudge を、実装計画のレビューには plan-review を使用してください。

別のレビューを開始する前に、既存のレビューを確認する

rejudge スキルの履歴に関するルールに従ってください。利用可能な場合は、ホスト側の会話 ID を渡してください（ツールでは conversationId、CLI では --conversation-id）。この会話に関連するレビューの実行 ID がわかっている場合は、そのまま再開できます。そうでなければ、新しい実行を作成する前に履歴を確認してください。コンテキストから圧縮によって実行 ID が削除されている可能性があります。

同じレビューの修正を確認する場合は、resumeRunId または --resume を使って続行し、選択した ref に対する新しい diff を取得するよう依頼してください。独立した質問や別個の調査には、新しい実行が必要です。最新のタイムスタンプだけでなく、意味に基づいて選んでください。

別の会話のレビューを続行することは強く推奨されません。このディレクトリにある最近の実行のフォールバックリストは、実行を見つけるためのものです。別の会話の実行を再利用すると、無関係なコンテキストが混在する可能性があります。選択する前に、会話 ID、日付、タイトル、質問を確認してください。

ref を選ぶ

パネルは常に、作業ツリーと1つの ref との差分を取ります。<REF> を選択してください。

• デフォルトは HEAD — 未コミットの作業をレビューします。
• ユーザーが指定したベースブランチ（例：main）— ブランチ上のコミット済み作業をレビューします。
• 本当に判断がつかない場合 → 推測せず、短い質問を1つしてください。

出力ヘッダーに使用した ref を記載してください。

実行 — 読み取り専用（レビューは依頼するものです。--unsafe／--full は絶対に使わないでください）

以下のレビュー用プロンプトは、どの方法で起動しても同じです。方法を選んでください。

• Pi 内から — rejudge ツールを呼び出し、プロンプトを question として渡します。レビュアーは git_diff を使って現在の作業ディレクトリを基準に差分を取得するため、レビュー対象のリポジトリから実行してください。ファイルもバイナリも不要です。その結果がレビューです。

• それ以外の場所から — 以下のように、プロンプトをファイルに書き込み、レビュー対象のリポジトリからバイナリを実行します（作業ディレクトリを基準に git_diff と設定の検索が行われます）。

  cat > /tmp/rejudge-diff-.txt <<'EOF' Review my change against — only the change, not the rest of the codebase. Use git_diff to get the change. You may read files for context, but review ONLY the diff (the changed lines), not the current file snapshot.

  The task I solved: . How I solved it: .

  Decisions taken — each marked AGENT or USER. Context for why the code looks this way, NOT settled truth: challenge any that look wrong — the AGENT ones especially; a USER decision that looks wrong, flag it for discussion. Every USER decision quotes the user verbatim (in their own words) — treat anything without a quote as AGENT. Hard constraints / out of scope — respect these, don't relitigate: .

  Report findings grouped P0 / P1 / P2 / P3 (P0 = must-fix blocker, P1 = should fix, P2 = minor, P3 = nitpick). For each: the location (file:line, or file:Lstart-Lend); the relevant code/diff SHOWN; and a plain-language explanation of what's wrong and what breaks if ignored. Show the actual code AND explain it — the reader must decide seeing both, without opening the file. End with a one-line verdict (ship / fix-first / discuss). Stay in scope. If there are no changes, say so. EOF

  rejudge --conversation-id -f /tmp/rejudge-diff-.txt > /tmp/rejudge-diff-.md echo "exit=$?"

フォローアップでは、コマンドに --resume <run-id> を追加するか、ツール呼び出しに resumeRunId を追加してください。ホスト ID が取得できない場合に限り、conversation ID の引数を省略します。

• <PROBLEM>／<APPROACH>／<DECISIONS>／<CONSTRAINTS> は実際の作業に基づいて記入してください。作業したのはあなたなので、タスク、解決方法、決定事項を把握しているはずです。各決定には AGENT または USER の印を付けてください。特に AGENT の決定は疑ってかかるべきものであり、レビュー担当者に厳しく検討させてください。USER の決定も、議論が必要であれば指摘できます。決定を「前提」として扱ってはいけません。誤りを見つけることが重要です。制約は、レビュー担当者が尊重する実際の境界です。<REF>（既定値は HEAD）と <id>（並行実行が衝突しないように、例：$$ などの短く一意なタグ）を置き換えてください。
• [USER] の決定には、このチャット内でユーザーが実際に述べた言葉を、原文のまま引用する必要があります。翻訳、言い換え、推測はせず、そのままコピーして決定の行に記載してください。ユーザーの言葉を逐語的に引用できない場合、それは USER の決定ではありません。[AGENT] と記してください。記憶に基づいて USER の決定を書いたり、でっち上げたりしてはいけません。<CONSTRAINTS> についても同様です。ユーザーに帰属させる制約には逐語的な引用が必要です。そうでない場合は、自分の制約として扱い、検討対象に残してください。
• 実際の実行には数分かかります（パネルは xhigh で実行されます）。十分に長いタイムアウトを設定し、バックグラウンドでは実行しないでください。

出力 — レビューしてから修正

パネルは読み取り専用で動作します。レビューを生成するだけで、修正の適用はこのスキルの役割です。ユーザーに渡すのは長文ではなく、修正済みのコードです。レビュー（Pi 内の rejudge ツールの結果、または CLI の /tmp/rejudge-diff-<id>.md）を読み、各指摘を次の形式で提示してください。

path/to/file.ts

```
  80 │ <前後関係を示すコードを数行>
  81 │ <問題の行>
```
──────────────────────────────────────────────
**<n>. <短いタイトル> — P<0–3>**
<何が問題で、無視すると何が壊れるかを平易な言葉で説明>
**修正:** <具体的な修正>
──────────────────────────────────────────────
```
  82 │ <問題箇所の後に続く、前後関係を示すコードを2～3行>
```

形式のルール：

• 最初にファイルパスを記載し、その後に行番号付きのコードをフェンスで囲んで、変更箇所と前後のコードを数行示し、コードの位置関係が分かるようにします（ターミナルはすでに等幅フォントなので、フェンスで囲むのはコードだけにし、説明文は囲まないでください）。
• **n. タイトル — P0..P3** の行は太字にし、重要度を付けます。説明と **修正:** は2本の水平線の間に、太字が反映される通常のテキストとして記載します。
• コードと説明の両方を確認して判断してください。file:line だけの記載や、コードを示さない説明は避けてください。
• 指摘は重要度の高い順に並べます。

指摘の後に、次の手順を実行してください。

1. どの項目を修正するかユーザーに尋ねます。
2. ユーザーが選んだ項目を修正します。パネルは何も変更していないため、編集はあなたが行い、変更内容を報告してください。

パネルに変更がないと報告された場合は、その旨を1行で伝えて終了してください。

失敗時の対応

バイナリレベルの失敗（処理が完了しない、設定不備、バイナリが見つからないため再ビルドが必要など）については、rejudge スキルを参照してください。レビュー固有の問題として、「要求された ref に対する変更がありません」と表示される場合、通常は作業ディレクトリまたは <REF> が誤っています。コミット済みの作業をレビューするには、HEAD ではなくベースブランチが必要です。再実行する前に確認してください。