rejudge-diff

Rejudge Diff

通过 Rejudge 进行代码审查——这是将 /rejudge 指向一个差异。请先阅读 rejudge 技能：在 Pi 中调用 rejudge 工具；只有在未提供该工具时才使用 CLI。此技能负责审查提示词和结果呈现。面板以只读方式运行，并通过 git_diff 获取差异。

对于通用的多模型问题，请使用 rejudge；对于实现计划审查，请使用 plan-review。

开始新的审查前，先查找现有审查

遵循 rejudge 技能的历史记录规则。尽可能传入宿主对话 ID（在工具中使用 conversationId，在 CLI 中使用 --conversation-id）。如果已知与本次对话相关的审查运行 ID，可以直接恢复。否则，在创建新运行前先检查历史记录；上下文压缩可能已将其 ID 移出当前上下文。

检查同一审查的修复时，请使用 resumeRunId 或 --resume 继续，并要求针对所选 ref 获取最新差异。独立问题或单独的研究需要新运行。应根据含义进行选择，而不能只看时间戳的新旧。

强烈不建议从另一段对话继续审查。 此目录中的近期运行备用列表用于发现审查；复用其他对话的运行可能会混入无关上下文。选择前请检查其对话 ID、日期、标题和问题。

选择 ref

面板始终将工作树与一个 ref 进行差异比较。选择 <REF>：

• 默认使用 HEAD——审查未提交的工作；
• 使用用户指定的基分支（例如 main）——审查分支上的已提交工作；
• 确实存在歧义时 → 提出一个简短问题，不要猜测。

在输出标题中注明所用的 ref。

运行 — 只读（审查只是请求；绝不使用 --unsafe/--full）

无论以哪种方式启动，下面的审查提示词都相同。选择一种方式：

• 在 Pi 中 — 将提示词作为 question 调用 rejudge 工具。审查者会通过针对 cwd 的 git_diff 获取差异，因此请从待审查的仓库中运行。无需文件或 bin。其结果就是审查内容。

• 在其他任何地方 — 将提示词写入文件，并从待审查的仓库中运行 bin（cwd 决定 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** 这一行使用粗体并标注严重级别；说明和 **修复：** 放在两条水平分隔线之间，作为普通文本，以便粗体能正常显示。
• 结合代码和文字进行判断——不要只写 file:line，也不要只写说明而不展示代码。
• 按 P0 优先级从高到低排列发现。

列出发现后：

1. 询问用户想修复哪些问题。
2. 应用用户选择的问题——面板没有做任何改动（它是只读的），由你来修改代码——然后报告你改了什么。

如果面板报告没有变更，用一句话说明并停止。

故障模式

对于二进制级故障（未完成、配置错误、缺少二进制文件 → 需要重新构建），请参阅 rejudge 技能。审查相关问题：“没有相对于指定引用的变更”通常表示工作目录或 <REF> 错误——已提交的工作需要以基础分支为参照，而不是 HEAD。重新运行前请确认。