sol-loop

sol-loop

これは、プルリクエストを作成する前（場合によっては作成した後）に、コード変更の正確性を高めるためのワークフローです。要約すると、OpenAI の GPT Sol を使ってコードを繰り返しレビューします。

Sol のレビュアーを満足させるため、可能な限り最小限の変更にしてください。スコープクリープに注意し、必要な場合は臆せず反論してください。

予算

• デフォルト：合計 3 ラウンドです。1 ラウンド目は全体を対象にします。以降のラウンドでは、変更したコードと未解決の指摘のみを確認します。
• セキュリティ、権限、認証、データ損失、状態管理／並行処理に関する問題で、根拠を示したうえで blocker または should が未解決の場合に限り、5 ラウンドまで延長します。ユーザーから依頼された場合も同様です。
• あるラウンドで指摘が軽微なものだけになった場合は、早めに終了します。却下した軽微な指摘や、コメント、ドキュメント、フォーマットのみの修正には、新たなラウンドは不要です。
• レビュアーは 1 人だけにします。Sol にサブエージェントやレビュアーを開始させてはいけません。
• 記録を付けます：ID、重要度、結果、返された場合は使用量。使用量を推測してはいけません。

1. スコープ

git status --short を実行します。無関係な変更を退避、破棄、または含めてはいけません。変更パスを明確に分けられる場合は、そのパスだけをレビュー対象にします。分けられない場合は、停止して確認を求めます。

git fetch origin の後、ベースを特定します。

• PR：gh pr view <n> --json baseRefName,headRefOid。ワークツリーがクリーンな場合に限り、ブランチをチェックアウトします。HEAD が PR の head と一致すること、またはこの変更分だけ先行していることを確認します。ベースは git merge-base HEAD origin/<baseRefName> です。
• ローカル：git merge-base HEAD origin/<default-branch>。リモートがない場合は、ユーザーが指定したベース、または未コミットの変更のみであれば HEAD を使用します。

変更とは、対象パスにおけるベースからワークツリーまでの差分と、追跡対象外ファイルです。すべてのラウンドで同じ diff コマンドを使用します。意図とスコープ外の内容を 1～2 文で述べます。対象範囲をカバーするチェックを実行します。この変更で失敗するコードを送ってはいけません。不足しているチェックや、変更前から失敗しているチェックがあれば、概要に記載します。

2. Sol を開始する

T3 では、orchestrator_capabilities を呼び出します。ユーザーがバージョンを指定していない場合は、最新の Sol を選びます。ID をハードコードしてはいけません。公開されている場合に限り、プロバイダー、モデル、エフォートを記録します。すべてのラウンドで delegate_task（role: "review"、mode: "async"）を使用します。taskId を保存します。ラウンドごとに新しい clientRequestId を使用します。childThreadId は保存先であり、次の対象ではありません。レビューに t3_thread_send、create_threads、t3_thread_launch を使用してはいけません。

T3 ツールが一覧にない場合は、直接の機能呼び出しを 1 回試します。T3 の外では、ネイティブの Sol サブエージェントを使用し、その ID を保持します。Claude Code では、Sol を実行するよう設定されている場合に限り、カスタムサブエージェントを使用します。Sol を実行する手段がない場合は、ブロッカーを報告します。別のモデルで代用してはいけません。

レビュー中は対象ファイルを編集してはいけません。通知が届くまで待ちます。ポーリングしたり、2 人目のレビュアーを開始したりしてはいけません。タイムアウト、エラー、返信なしは承認ではありません。失敗した場合は、キャンセルして停止を確認し、記録を引き継いで再開します。

1 ラウンド目の概要（T3 の子スレッドには履歴が渡されません）：

Review only. Do not edit, commit, push, comment on PRs, or start subagents.
Repo: <abs path> Base: <sha> Intent: <intent> Out of scope: <scope> Checks: <results>
See: git diff <base> [-- <paths>]; git status --short (read untracked).
Read surrounding code. Find bugs, broken callers, mismatch with intent.
Skip style unless it hides a bug. Hold to the smallest change. Flag code,
tests, or guards the intent does not need. Other paths, rare cases, small
perf, extra compat: nits.
blocker = intended case wrong. should = real bug callers will hit, in intent. nit = rest.
Reply:
VERDICT: APPROVE or CHANGES
S1 [blocker|should|nit] <file>:<line> <claim>. Fix: <suggestion> (stable ids)

3. 指摘への回答

各指摘と重要度を自分で確認します。別の経路、まれなケース、または小さなコストに関する指摘は、どのようなラベルが付いていても軽微なものです。

• 同意する場合：最小限の修正を行います。新しいロック、キャッシュ、ヘルパー、オプションを追加するより、削除または範囲の縮小を優先します。実際に発生したケースを修正します。意図の確認が必要な場合は、その修正がなければ失敗する、対象を絞ったテストを 1 つ追加します。
• 同意しない場合：根拠（ファイル：行、テスト、出力）を示して理由を述べます。
• スコープ外または軽微な場合：1 行で却下します。フォローアップとして一覧にします。

記録を更新します。チェックを再実行し、git diff --shortstat <base> を実行します。レビューによって diff が大きくなった場合は、まず縮小します。ループを終わらせるためだけに同意してはいけません。

4. 次のラウンド

予算が残っていて、blocker または should が未解決である場合、動作に関するコードを変更した場合、または現在の動作差分が承認の対象になっていない場合に限り、新しいラウンドを開始します。T3 では新しい delegate_task を使用し、ネイティブの ID を保存している場合はそれに追跡依頼を行います。1 ラウンド目の概要、記録（fixed:／disagree:／declined: と根拠）、同じベースとの差分、前回からの変更を送ります。Sol には、未解決の ID と変更したコードだけを確認するよう伝えます。古い ID ごとに resolved または still open: <reason> と記録します。

5. 停止して出荷する

合意：現在の動作差分を承認し、ブロッカーや要対応事項はなく、独自の懸念もありません。行き詰まり：2 回の返信後も項目について意見が分かれたままの場合、または予算が尽きた場合です。双方の主張をそれぞれ 2～3 行で示します。判断はユーザーに委ねます。 予算切れは承認を意味しません。

ループ中はプッシュしないでください。合意後、ユーザーからプッシュ、出荷、または PR の更新を依頼された場合にのみプッシュします。PR にプッシュする場合は、モデルの説明文の上に次を追加します。

Reviewed with sol-loop: <N> rounds with <model>. Sol verdict: approved.

確認できた場合にのみ on <effort> を追加します。

報告内容：ラウンド数、モデル、Sol が変更した内容、変更前後の差分サイズ、修正した指摘と却下した指摘およびその理由、利用状況（確認できる場合。確認できない場合はその旨を記載）、プッシュの有無。