コードレビュー

/review を使用して、コードの変更を正確性、セキュリティ、パフォーマンス、コード品質の観点からレビューします。

クイックスタート

# Review local uncommitted changes
/review
 
# Review a pull request (by number or URL)
/review 123
/review https://github.com/org/repo/pull/123
 
# Review and post inline comments on the PR
/review 123 --comment
 
# Review local changes and apply the findings to your working tree
/review --fix
 
# Continue a review of the same PR that was interrupted, instead of starting over
/review 123 --resume
 
# Review a specific file
/review src/utils/auth.ts
 
# Quick unverified pass (no subagents)
/review --effort low
/review 123 --effort medium

コミットされていない変更がない場合、/review はその旨を通知して停止します。エージェントは起動されません。

努力レベル

--effort low|medium|high は深さと速度のトレードオフです。

デフォルト: PRレビューにはhigh、ローカルおよびファイルレビューにはmedium。有効な --comment はhighを強制します（投稿されたコメントは検証を生き残る必要があります）— PR以外のターゲットでは --comment は警告とともに無視され、努力レベルは変更されません。Mediumはセキュリティとテストカバレッジのエージェントとビルド/テストを保持し、敵対的ペルソナ、diff特化型ファインダー、逆監査を削除します。そのため、2回目のチェックでのみ表面化するような微妙なCriticalが見逃される可能性があります。セキュリティに敏感なレビューやリリース前のレビューには --effort high を使用してください。未検証なのは low だけです。Worktreeの分離は同一リポジトリのPRレビューに適用されます。クロスリポジトリPRは軽量モード（diffのみ、worktreeやビルド/テストなし）で実行されます。Lowパスは未検証とラベル付けされ、判定を発出せず、増分レビューキャッシュを書き込みません。そのため、後続の --effort high の実行が「レビュー済み」としてスキップされることはありません。Mediumは検証済みですが、ApproveはCommentにキャップされます。1回目のパスで見逃したものを2回目に見るものがないためです。diffの取得メカニズムはすべてのレベルで同一です。PRレビューは常に分離されたworktreeと同一のベース解決を使用するため、レビューが誤ったベースに対して行われることはありません。1つのスコープの違いが残ります: 増分キャッシュはhighのみで使用されるため、highの再レビューは新しいコミットのみ（lastCommitSha..HEAD）をカバーする場合がありますが、low/mediumは常にPR diff全体をレビューします。

仕組み

/review コマンドは多段階のパイプラインを実行します。

Step 1:  スコープ + 努力レベルの決定（ローカル diff / PR worktree / ファイル）
         diffをファイルにキャプチャ + チャンクに分割
Step 2:  プロジェクトのレビュールールを読み込む（medium/high）
Step 3C: low effort: 3-6 インライン角度 + ギャップスイープ     [0 サブエージェント呼び出し]
Step 3A: high, <=500 src かつ <=3200 total: 14 エージェント       [14+ LLM calls]
           |-- Agent 0: Issue Fidelity & Root-Cause Ownership
           |-- Agent 1a: 正確性 — 行単位スキャン
           |     （言語の落とし穴 + ラッパールーティングチェック含む）
           |-- Agent 1b: 正確性 — 削除された動作の監査
           |-- Agent 1c: 正確性 — クロスファイルトレーサー
           |-- Agent 2: セキュリティ
           |-- Agent 3a: 再利用と重複
           |-- Agent 3b: 抽象度と抽象化の適合性
           |-- Agent 3c: 一貫性と明瞭性
           |-- Agent 4: パフォーマンスと効率
           |-- Agent 5: テストカバレッジ
           |-- Agent 6: 非構造化監査（3つのペルソナ: 6a/6b/6c）
           |-- Agent 8: Diff特化型ファインダー（0-2、diffの
           |     ドメインが必要とする場合のみ）
           '-- Agent 7: ビルドとテスト（シェルコマンドを実行）
Step 3B: high, >500 src または >3200 total: テリトリー × 次元   [N+5..7+3H calls]
           （Nチャンク、5-7のwhole-diffエージェント、
            重いファイルHごとに3つの不変エージェント）
           |-- ~400 diff行ごとに1チャンクエージェント（全次元、
           |     自身のテリトリーのみ、カバレッジレシートを返す）
           |-- 大幅に書き直されたソースファイルごとに
           |     3つの不変エージェント（ファイル全体; state/timers、
           |     counters/returns/errors、config/early-returns）
           |-- Agent 0: Issue Fidelity     （diff全体）
           |-- Agent 7: ビルドとテスト       （リポジトリ全体）
           |-- Agent 1b: 削除された動作     （diff全体 —
           |     チャンク間半分; チャンクはローカル半分を保持）
           |-- Agent 1c: クロスファイルトレーサー（diff全体）
           |-- Agent 8: 特化型ファインダー（diff全体、0-2）
           '-- テストカバレッジマトリックス    （diff全体）
Step 4:  重複排除 --> シャード検証（エージェントごとに<=8発見）
           --> 集約                    [ceil(F/8) calls, F=発見数]
Step 5:  反復逆監査、チャンクごとにファンアウト;
         2回連続のドライラウンド後に停止（トポロジーによりキャップ 10/5/3）
Step 6:  結果と判定の提示（high; lowパス: 結果のみ）
         結果を正規化 -> .qwen/tmp/...-findings.json
Step 6B: 結果の適用 + 結果ごとのアウトカム記録  （--fix のみ）
Step 7:  PRレビューの提出（インラインコメント、要求された場合; highのみ）
Step 8:  レポートと増分キャッシュの保存（キャッシュ: highのみ）
Step 9:  クリーンアップ（worktreeと一時ファイルの削除）

Steps 3A/3B/4/5 は高努力パイプラインです。--effort low|medium では、単一のインラインパス（Step 3C）がこれらを置き換えます。

レビューエージェント

3つの正確性エージェントは手続的です。それぞれがdiffの歩き方（行単位 / 削除行 / クロスファイルエッジ）によって定義され、バグの分類によって定義されないため、カバレッジは重複せず補完的です。同じ理由でコード品質も3つに分割されます（3a/3b/3c）。6項目のチェックリストを持つ1つのエージェントは、大幅に書き直されたファイルで測定すると1項目しか完了しません。8項目のチェックリストを持つ1つのエージェントは5つの欠陥のうち1つを見つけましたが、同じモデルを3つに分割するとすべてを見つけました。そのため、品質チェックリストは質問が genuinely 異なる場所で分割されています。すべてのエージェントは並列で実行されます（Agent 1は3つの手続的バリアントを、Agent 3は3つのチェックリストスライスを、Agent 6は3つのペルソナバリアントを同時に起動し、同一リポジトリのPRレビューでは合計14の並列タスクになります。diffのドメインが必要とする場合に0-2のAgent 8ファインダーが追加されるため、実際には14-16です。Agent 0はローカルdiffおよびファイルパスのレビューではスキップされるため、13-15になります。クロスリポジトリの軽量モードではAgent 1cと7もスキップされ、12-14になります）。

すべての発見は失敗シナリオを明示する必要があります。それをトリガーする具体的な入力、状態、またはタイミング、および結果として生じる誤った出力です（品質の発見の場合は、具体的なコスト）。シナリオを名指しできない発見はソース段階で削除され、検証は発見の文章を判断するのではなく、主張されたシナリオを実際のコードを通じて再トレースします。

PRが500行を超えるソース変更、または合計3,200行を超えるdiff行を持つようになると、11のwhole-diffリーダーがそれぞれ注意深く読むには薄まりすぎるため（これは注意力の境界であり、呼び出し数の約束ではありません。重いファイルと特化型ファインダーにより、3Bのコストがより高くなる可能性があります）、この次元ファンアウトはテリトリー × 次元のファンアウトに置き換えられます。diffは約400行のチャンクに分割されます。境界はハンクの境界に配置され、大きすぎるハンクはトップレベルの宣言でのみ分割され、関数内部では分割されません。各チャンクは独自のエージェントを受け取り、そのチャンクだけにすべてのレビュー次元を適用します。

ゲートは意図的にdiff行ではなくソース行をカウントします。テストコード、プロセ、ロックファイルはdiffサイズを支配します。このリポジトリの過去40のマージされたPRでは、中央値のdiffは41%がテストでした。そのため、生サイズに基づくゲートは、489行の新規テストを出荷したというだけで173行の本番コードの変更をテリトリーに分割し、その本番コードは10のレンズではなく1つのレビュアーしか持てなくなります（diff読み取り次元エージェント — Issue FidelityとBuild & Testを除いた12）。どちらの場合でも、チャンキングはテストを含めすべての行をカバーします。ゲートが決定するのは、何人のレビュアーがいるかと、それぞれが何を求められているかです。1つの大きなdiffを歩く10のdiff読み取りレンズは、同じ初期ハンクを10回繰り返し読みます。チャンクごとに1つのエージェント意味着、diffのすべての行にちょうど1つの責任あるレビュアーが存在します。各チャンクエージェントは Covered: レシートを返し、レシートのないチャンクは実行が進行する前に再レビューされます。そのため、「ブロッカーなし」が誰も読んでいないコードに対して報告されることは決してありません。

大きく書き直されたソースファイル（300行以上の既存ファイルで40%以上が新しい、または800行以上の変更行がある）には、3つのファイル全体不変エージェントも割り当てられます。テストファイルと生成ファイルは対象外です。チェックリストはフィールド、タイマー、エラー分類について尋ねますが、書き直されたテストファイルにはそれがありません。そのバグは通常、どのハンク内ではなく_行間_にあります。ファイルの上部付近で設定されたタイマーと、二千行下のティアダウンパスです。各エージェントは変更後のファイル全体を読み、固定チェックリストの2-3項目を辿ります。すべての出口パスでクリアされるミュータブルフィールド、すべてのクローズでキャンセルされるタイマー（およびキャンセルがキャプチャされたデータを破棄しない）、マップの挿入と削除の一致、すべてのエントリでインクリメントされるリトライカウンタ、実際にチェックされるステータス戻り値、永続/一時的なエラーコードの網羅的な分類、すべてのパスで尊重される設定フィールド、および必要な副作用をスキップする早期リターンです。

チェックリストは意図的に3つに分割されています。2,400行のファイルですべての8つのチェックを1つのエージェントに渡すと、1つしか適切に完了しません。2-3つのチェックを持つ3つのエージェントは、すべてを完了させます。チャンクエージェントはこれの代わりにはなりません。PR #6457では、これらの欠陥をすべて自身のテリトリー内に保持しながら1つも報告しませんでした。足りなかったのは行ではなく、質問でした。

発見はシャードバッチで検証されます（検証エージェントごとに最大8つの発見、すべて同時に起動）。検証者は、それに矛盾するコードを引用することによってのみCriticalを拒否できます（またはdiff自体のコメントがフラグ付きの動作を意図的なものとして文書化している場合）。それより不確かなものは、削除されるのではなく低信頼度にダウングレードされます。サイレントに拒否されたCriticalは後続のすべてのステージから見えなくなりますが、ダウングレードされたものは引き続き人間の目に届きます。検証後、反復逆監査がギャップを探し、1ラウンドにつきチャンクごとに1人の監査者をファンアウトします。各監査者は累積的な発見リストを持ちます。このループは2回連続のドライラウンド（またはプランのラウンド上限 — 収束ではなくそのように報告）後に停止します。上限は diff のトポロジーに従います: 小規模な diff では 10（ラウンドは単一の監査者）。チャンク付きでは 5（ラウンドごとにチャンクごとに1人の監査者）。巨大な diff（≥ 3000 効果行）で実行にデッドラインがある場合は 3（5 回の約 90 分のラウンドが 6 時間の CI 上限に収まらないため。デッドラインがない場合、巨大な diff はチャンク付きの上限 5 を維持します）。オペレーターは review.reverseAuditRounds 設定で、すべてのレビューに適用される上限を引き下げることができます。引き上げることはできません。1回のドライラウンドは収束の証拠ではなく、逆監査の発見も他の発見と同様に検証されます。

重大度レベル

低信頼度の結果は、ターミナル内の「要人間レビュー」という別のセクションに表示され、PRコメントとして投稿されることはありません。

Worktree の分離

PRをレビューする際、/review は現在のブランチを切り替える代わりに、一時的なgit worktree（.qwen/tmp/review-pr-<number>）を作成します。これにより以下のことが保証されます。

• ワーキングツリー、ステージされた変更、および現在のブランチが変更されることは決してありません
• ビルド/テストが機能するように、worktree内に依存関係がインストールされます（npm ci など）
• ビルドおよびテストコマンドは、ローカルのビルドキャッシュを汚染することなく、分離された環境で実行されます
• 何かがうまくいかない場合でも、あなたの環境には影響しません。worktreeを削除するだけです
• レビュー完了後、worktreeは自動的にクリーンアップされます
• レビューが中断された場合（Ctrl+C、クラッシュ）、同じPRに対する次回の /review は、新しく開始する前に古いworktreeを自動的にクリーンアップします。中断されたセッションがまだリースを残している場合 — これをスキップするハードキル、または後のプロンプト中に中断されたマルチプロンプトレビュー — /review は拒否し、削除対象のリースファイルを通知します。クリーンな停止はそれをリリースします。完了したレビューと早期停止（空のdiff、前回のレビュー以降の新しい変更なし）はすべて cleanup を実行し、リースをリリースします
• worktreeはそのセッションにリースされます。すでにレビュー中のPRに対する2回目の /review は、実行中のレビューのworktreeを破壊する代わりに、開始を拒否します（保持者を通知します）
• レポートとキャッシュはメインのプロジェクトディレクトリに保存されます（worktreeではありません）
• コードを変更して何かを測定するステップ — テスト有効性プローブのミュータント、および検証器の特定の発見のプローブ — はそれぞれ、隣の独自の使い捨てworktree（…-probe、…-scratch-<agent>）で実行されるため、あるエージェントの実験が共有ツリーを読む他のエージェントから見えません。最後の手段として、各ウェーブのすべてのエージェントには、起動時点でレビュー対象のコミットと異なるパス（あれば）と、それらのパスに限定された失敗は発見ではないことが伝えられます。これらのツリーはすべて、レビュー終了時にworktreeと一緒にスイープされます

他リポジトリのPRレビュー

完全なURLを渡すことで、他のリポジトリのPRをレビューできます。

/review https://github.com/other-org/other-repo/pull/456

これは軽量モードで実行されます。worktreeもビルド/テストもありません。レビューはdiffテキストのみ（GitHub API経由で取得）に基づいて行われます。書き込み権限がある場合は、PRコメントを引き続き投稿できます。

PRインラインコメント

結果をPRに直接投稿するには、--comment を使用します。

/review 123 --comment

または、/review 123 を実行した後に post comments と入力すると、レビューを再実行せずに結果を公開できます。

投稿される内容:

• 特定の行に対するインラインコメントとしての、高信頼度の Critical および Suggestion の結果。それぞれに **[Critical]** または **[Suggestion]** のプレフィックスが付き、ブロッカーと推奨事項を区別できます
• 修正が単一のローカライズされた編集である場合、ワンクリックで適用できる ```suggestion ブロック
• Approve/Request changes の判定の場合: 判定を含むレビュー要約
• すべてのインラインコメントが投稿された Comment の判定の場合: 個別の要約はなし（インラインコメントで十分）
• 各コメントのモデルとCLIバージョンの帰属フッター（例: — qwen3-coder via Qwen Code /review (v0.21.2)）。ユーザーまたはシステムの settings.json で review.attribution を false に設定すると、帰属フッターなしで投稿できます（ワークスペースの .qwen/settings.json は review.* の設定では無視されます）— コメントとボディリストは **[Critical]**/**[Suggestion]** の重大度マーカーも失い、モデルはレビューのマシンレジャーマーカーから差し止められるため、新しい環境（レビューキャッシュなし）では、回復されたインクリメンタルアンカーが同一モデルチェックに失敗し、再レビューが全範囲にフォールバックします

ターミナルのみに留まる内容:

• Nice to have の結果
• 低信頼度の結果

自身が作成したPR: GitHubでは、自身のプルリクエストに対して APPROVE または REQUEST_CHANGES のレビューを提出することはできません。どちらもHTTP 422で失敗します。/review がPRの作成者が現在認証されているユーザーと一致することを検出すると、判定に関係なくAPIイベントを自動的に COMMENT にダウングレードするため、提出は成功します。ターミナルには引き続き正直な判定（“Approve” / “Request changes” / “Comment”）が表示されます。GitHub側のレビューイベントのみが無効化されます。実際の結果は引き続き特定の行にインラインコメントとして表示されるため、実質的なフィードバックは変わりません。

以前の Qwen Code コメントがあるPRの再レビュー: /review が以前の Qwen Code レビューコメントをすでに持っているPRで実行されると、新しいコメントを投稿する前にそれらを分類します。同一行の重複（新しい結果と同じ (path, line) に既存のコメントがある場合）のみ、確認を求められます。これは、同じコード行に視覚的な重複が表示されるケースです。古いコミットからのコメント、返信されたコメント（解決済みとして扱われる）、および新しい結果と重複しないコメントは、サイレントにスキップされます。ターミナルのログ行に何がフィルタリングされたかが表示されます。

APPROVE前のCI/ビルドステータスチェック: 判定が “Approve” の場合、/review は提出前にPRのチェック実行とコミットステータスをクエリします。いずれかのチェックが失敗している場合（またはすべてのチェックがまだ保留中の場合）、APIイベントは自動的に APPROVE から COMMENT にダウングレードされ、レビュー本文にその理由が説明されます。理由: LLMレビューはコードを静的に読み取るため、ランタイムのテスト失敗を確認できません。CIが赤い間に承認することは誤解を招く可能性があります。インラインの結果は引き続き変更なしで投稿されます。とにかく承認したい場合（例: 既知の不安定なCI失敗）、確認後にGitHubの承認を手動で提出してください。

結果の適用（--fix）

--fix は --comment を反転させたものです。--comment はプルリクエストに書き込むため、PRが必要です。--fix はワーキングツリーに書き込むため、レビューより長く存続するものが必要です。

/review --fix                 # ローカルの未コミットの変更
/review src/auth.ts --fix     # 単一のファイル

PRターゲットでは警告とともに無視されます。PRレビューは一時のworktreeで実行され、レビュー終了時に削除されるため、「修正された」編集は数分後に破棄されます。代わりに --comment を使用して結果を公開してください。

有効な --fix は努力レベルをmedium以上に設定します。ファイルを編集し、low は検証を実行しないためです。未検証の結果を適用することは、誰かのPRではなくあなたのワーキングツリーに向けられているという同じ間違いです。high は強制しません。mediumの結果は検証済みであり、high が追加する逆監査は_不足している_発見を探すもので、適用するかどうかの判断には関係ありません。

レビュー後、各発見は edit ツールで適用され、その後アカウンティングされます。3つの方法のいずれかです。

発見は、その修正が意図された動作を変更する場合、レビューされたdiffの範囲外の変更を必要とする場合、または再検討で偽陽性と判明した場合はスキップされます。

すべての発見にはアウトカムが与えられ、これは要求ではなく強制されます。 台帳は qwen review findings --outcomes を経由し、すべてをカバーしないセットを拒否します。9つの発見のうち6つを適用して6つと報告するフィクサーは、どれについても嘘をついてはいません。リストをサイレントに短縮しており、脱落した3つを確認する手段がありません。

中断されたレビューの再開（--resume）

途中で終了した長いレビュー — 接続の切断、タイムアウト、キルされたターミナル — は、実行したすべてをディスク上に残します。worktree、キャプチャされたdiff、および実行されたすべてのエージェントのハーネス自身の記録です。--resume は最初からやり直す代わりに、そこから続行します。

/review 123 --resume

これはPRターゲットにのみ適用されます（ローカルレビューのdiffはライブのワーキングツリーから取得されるため、続行するための安定した中断状態がありません）。不确定な場合はいつでも安全に渡せます。レビューはディスク上の状態自体 — フェッチされたコミットにまだ存在してクリーンなworktree、バイト単位で変更されていないキャプチャされたdiff、移動していないPRヘッド、未消費の再開上限 — をチェックし、一致しないものがある場合はサイレントに最初から開始して、どのチェックが拒否したかを通知します。続行は前の試行の認定されたエージェント結果を再利用するため、レポートに回復された数が表示されます。開示され、カバレッジのギャップになることはありません。

2つ知っておくべきことがあります。続行は中断された実行の努力レベルを保持します。異なる --effort を渡すと再開を拒否し、要求されたレベルで新しく実行します。異なる努力レベルは異なる作業のためです。そして、レビューが停止している間にPRヘッドが移動した場合、再開は拒否（head-moved）し、新しい実行が新しいコミットをレビューします。これがあなたの望む動作であり、このレビューの1回の再起動としてカウントされます。

データとしての発見

確認された発見は、他の何かが消費する前に .qwen/tmp/qwen-review-<target>-findings.json に正規化されます。ターミナルレポート、保存されるMarkdownレポート、PRレビューJSONはすべて、リストを再作成するのではなく、その1つの成果物を読み取ります。各発見は一意の id（アウトカムと解決アンカーが結合するキー）、severity、confidence、source、summary、リスト表示用に60文字に制限された shortSummary、failureScenario、および1つ以上の locations を持ちます。パターン集約された発見は発生ごとに1つのlocationを保持するため、それぞれが独自のインラインコメントを受け取ります。

何よりもまず、レビューは自身のコードを実行していることを確認します。 すべての qwen review … ステップはワーキングツリーではなくビルドされたバンドルを実行するため、最後のビルド以降にレビューコマンドを編集しても効果がなく、実行は古い動作を測定します。ビルドはバンドルしたレビューソースのダイジェストを記録し、parse-args が再導出と比較を行い、drive が再度チェックします（検証エージェントのブリーフはステップ1を経ずに直接そこに送られるため）。ミスマッチがある場合、バンドルがこれらのソースからビルドされなかったことを stderr に出力し、何をリビルドすべきかを示します。このチェックはCLIがバンドルされた dist/cli.js（qwen バイナリ、または node dist/cli.js）に解決される場合に実行されます。npm start や npm run dev などのバンドルされていない出力を実行するランチャーはスキップされます。比較できない2つのケースは異なる方法で処理されます。ビルドが記録より前のチェックアウトには、チェックを実行できなかった理由が伝えられ、ソースが存在しないインストール済みパッケージは静かに無視されます。ダイジェストはレビューコマンド、それらを登録するファイル、ディレクトリ外からインポートするレビュー専用のリース、およびバンドルされたレビュースキルをカバーします。それらがインポートする共有ヘルパーまでは追跡しないため、静かな実行はレビューコードがバンドルと一致することを意味し、ツリー全体が一致することを意味するわけではありません。

ベースツリーがすでに失敗していたCriticalは記録されず、ファイルされません。 テストコマンドが失敗し、マージベースがビルドできた場合、test-delta は失敗したファイルのうちプルリクエストなしでも失敗するものを記録します。正規化はその測定を読み戻します（qwen review findings --test-delta、--outcomes の横）。自身のテキストがそれらのファイルの1つを名指しするCriticalはSuggestionに降格され、証拠を保持し、降格した測定と heldByMeasurement フィールドを獲得し、降格がアナウンスされます。すでに赤かったテストは、このプルリクエストが赤くしたテストではありません。そして、_新しい_理由で失敗するようになった場合は、どのテストかを述べ、両側を引用し、再度Criticalとしてファイルしてください。すでに測定を持つ発見がそのまま上げられた場合、あなたが置いた場所にそのまま残されます。

コマンドは書き込み時に検証します。重複するid、失敗シナリオのない発見、空のlocations配列、または不明な重大度は、サイレントに壊れたエントリではなくエラーです。

PRコメント内の証拠画像

GitHubのAPIはレビューコメントに画像を添付できないため、/review はあなたが指定するリポジトリで証拠画像（TUIスクリーンショット、レンダリング出力の比較）をホストし、URLで埋め込むことができます。

export QWEN_REVIEW_ASSETS_REPO=your-org/your-repo   # プッシュできるリポジトリ
/review 123 --comment

メンテナーは通常、レビュー対象のリポジトリを指定します。それ以外の人はフォークまたはスクラッチリポジトリを使用できます。画像は pr-assets/<pr>-review ブランチにコンテンツハッシュ名で配置され、コメントはコミット固定URLで参照します。ブランチが後に移動しても不変であり、GitHub Enterpriseでも変更なく機能します。

GitHubトリガーのレビュー（PRレビューワークフロー）の場合、同じ変数が同じ名前のリポジトリ変数から配線されます。変数が未設定の場合、ワークフローは空の値を渡し、公開は拒否されます。何も変わりません。リポジトリのActions変数に QWEN_REVIEW_ASSETS_REPO を設定したメンテナー（通常はリポジトリ自身を指定）は、レビューコメントがキャプチャPNGを埋め込むことを有効にします。変数が同じリポジトリを指している場合、書き込みブランチは視覚的クリーンアップワークフローによってクリーンアップされます。フォークまたはスクラッチ宛先は独自の保持を管理します。

公開は投稿とまったく同じ方法でゲーティングされます。指定リポジトリがない場合は公開なし、不正な実行（有効な --comment なし）は submit が拒否するのと同じ方法で拒否されます。画像タイプのみが受け付けられ（SVGは意図的に除外）、サイズキャップがあり、各ファイルのバイトはその拡張子が主張する形式と一致する必要があります。誤ラベル付けまたは認識されないコンテンツは拒否されます。マニフェストがプッシュされたすべてのファイルを記録します。指定がない場合、発見は証拠をローカルファイルパスとしてターミナルと保存されたレポートに保持します。何も壊れず、コメントはテキストのみのままです。

フォローアップアクション

レビュー後、コンテキストに応じたヒントがゴーストテキストとして表示されます。Tabキーを押して受け入れます。

注: fix these issues はローカルレビューでのみ利用可能です。PRレビューではレビュー後にworktreeがクリーンアップされるため、レビュー後の対話的な修正はできません。代わりに --comment または post comments を使用して結果を公開してください。--fix が渡された場合、発見にはすでにアウトカムが含まれており、修正ヒントは提供されません。

プロジェクトのレビュールール

プロジェクトごとにレビュー基準をカスタマイズできます。/review は以下のファイルからルールを（順番に）読み込みます。

1. .qwen/review-rules.md（Qwen Code ネイティブ）
2. .github/copilot-instructions.md（優先）または copilot-instructions.md（フォールバック — 両方ではなくどちらか一方のみが読み込まれます）
3. AGENTS.md — ## Code Review セクション
4. QWEN.md — ## Code Review セクション

ルールはLLMレビューエージェント（0-6）に追加の基準として注入されます。PRレビューでは、悪意のあるPRによるバイパスルールの注入を防ぐため、ルールはベースブランチから読み込まれます。

リポジトリコンテキスト

リポジトリは、厳密なJSONマニフェストを .qwen/review-context.json にコミットすることで、レビュアーに対してリポジトリ固有のガイダンスを渡すことができます。mediumまたはhighの努力レベルで、/review はプランのキャプチャ後にマニフェストを読み取り、エージェントが起動する前に対応するガイダンスを添付します。

{
  "version": 1,
  "label": "Example repository",
  "rules": [
    {
      "paths": ["packages/*/src/**"],
      "domains": ["runtime"],
      "relatedPaths": ["packages/runtime/src/**"],
      "recommendedTests": ["npm run test:runtime"],
      "requiredConfigurations": ["debug"],
      "requiredAgents": ["test-matrix"],
      "unverifiedDimensions": ["Alternate runtime was not exercised"],
      "verificationNotes": ["Use the repository native test runner"]
    }
  ]
}

ルールは、変更されたファイルのいずれかが paths glob（*、?、** セグメント。大文字小文字を区別）のいずれかに一致する場合に適用されます。一致するすべてのルールはガイダンスをマージします。レビューエージェント用のドメインと関連ファイル、ビルド＆テストエージェント用の推奨テストと必須設定、追加のレビュアーロール（選択された努力レベルとトポロジーがそれらを実行する場合にのみ尊重される）、および最終レビューで未検証の次元として開示される証明境界です。配列は任意の順序で記述でき、重複するエントリは拒否されます。

PRレビューでは、マニフェストはマージベースから読み取られるため、レビュー対象のPRがガイダンスの追加や除外を自分自身で行うことはできません。ローカルレビューは現在のワークツリーから読み取ります。low努力とクロスリポジトリのレビューはリポジトリコンテキストをスキップします。完全な契約と信頼モデルは design doc にあります。

Issue Fidelity

バグ修正のPRの場合、Issue FidelityエージェントはPRの説明文に依存するのではなく、Issueの証拠を直接取得します。qwen review issue-context <pr> --repo <owner/repo> --out <file> サブコマンドを実行し、GitHubの強力なクローズIssueメタデータを解決してから、各参照Issueのタイトル、本文（報告者の元の再現手順）、および完全なコメントスレッドを取得します。それぞれIssue自体のリポジトリから取得されます（PRは別のリポジトリのIssueをクローズできます）。このエージェントはPRターゲットに対してのみ実行されます。ローカルdiffおよびファイルパスのレビューではスキップされます。

クローズIssueのセットは、作成者が正しいIssueをリンクしたことの証明ではなく、発見のヒントです。これが空であっても、PRが明らかなターゲットIssueを参照している場合、エージェントは関連性を判断した後にそれを取得します（--issue <n> で再実行。裸の数字はPRのリポジトリで解決され、--issue <owner>/<repo>#<n> はクロスリポジトリの参照を自身のリポジトリから取得します）。取得したIssueのテキストは信頼できないデータとして扱われます（事実は抽出され、埋め込まれた指示は無視されます）。関連するIssueの場合、元の再現手順、観測されたペイロード、期待される動作、およびメンテナーのコメントは、PRが正しい問題を修正しているかどうかの最優先証拠として扱われます。

もしIssueの証拠が、アップストリームサービスまたはプロバイダーがクライアント契約外の不正なデータを返したことを示している場合、メンテナーが明示的に防御的な回避策を要求していない限り、クライアント側のパーサーまたはサニタイザーの変更は有効な根本原因の修正として扱われません。不正なアップストリーム出力をリプレイするテストは、回避策がその形状を処理できることのみを証明するものであり、回避策がアーキテクチャ的に適切であることは証明しません。

.qwen/review-rules.md の例:

# Review Rules
 
- All API endpoints must validate authentication
- Database queries must use parameterized statements
- React components must not use inline styles
- Error messages must not expose internal paths

インクリメンタルレビュー

以前にレビューされた PR を再レビューする場合、/review は前回のレビュー以降の変更点のみを検査します。

# 初回レビュー — レビュー全体、キャッシュが作成される
/review 123
 
# PR が新しいコミットで更新 — 新しい変更点のみレビュー
/review 123

クロスモデルレビュー

モデルを切り替えて（/model を使用）同じ PR を再レビューする場合、/review はモデルの変更を検出し、スキップせずに全体レビューを実行します。

# モデル A でレビュー
/review 123
 
# モデルを切り替え
/model
 
# 再レビュー — モデル B で全体レビュー（スキップされない）
/review 123
# → "Previous review used qwen3-coder. Running full review with gpt-4o for a second opinion."

モデルマッチはスキップだけでなくインクリメンタルスコープもゲートします。「キャッシュされたコミットまでクリーンアップ」は前のモデルの判定であるため、キャッシュされたレビュー以降に新しいコミットが追加された場合、モデルの不一致は lastCommitSha..HEAD にスコープしません — 範囲は全体 diff となり、「Previous round was reviewed by qwen3-coder. Running full review with gpt-4o.」と記録されます。ただし、最後に投稿されたレビュー（下記）から現在実行中のモデルが証明したアンカーが回復された場合は除きます。その場合は範囲が代わりにスコープされます。前のラウンドの発見は引き続き持ち越されて再判定されます。アンカーのみが持ち越されません。キャッシュが存在しない、またはそのアンカーが使用できない場合（CI、別のクローン）も同じゲートが、最後に投稿されたレビューのマシンレジャーマーカーから回復されたアンカーに適用されます。現在実行中のモデルが証明した場合にのみインクリメンタル範囲をスコープします。異なるモデルによって証明されたマーカー、またはモデルを持たないマーカー（review.attribution をオフにして投稿されたレビュー、またはそのフィールドが存在する前のレビュー）は、全体 diff にフォールバックします。

キャッシュは .qwen/review-cache/ に保存され、コミット SHA とモデル ID の両方を追跡します。このディレクトリが .gitignore に含まれていることを確認してください（.qwen/* のようなより広いルールでも機能します）。キャッシュされたコミットがリベースで消去されていた場合、全体レビューにフォールバックします。Aone はキャッシュされたアンカーを異なる方法でルールします — 以下の段落を参照してください。high努力のレビューのみがキャッシュを参照または書き込みます。--effort low|medium のクイックパスは「レビュー済み」としてカウントされません。

レビューレポート

同一リポジトリ内のレビューの場合、結果はプロジェクトの .qwen/reviews/ ディレクトリに Markdown ファイルとして保存されます（クロスリポジトリの軽量レビューではレポートの永続化はスキップされます）。

.qwen/reviews/2026-04-06-143022-pr-123.md
.qwen/reviews/2026-04-06-150510-local.md

レポートには以下の情報が含まれます：タイムスタンプ、差分統計、ビルド/テスト結果、検証ステータス付きのすべての発見、および最終判定。セクション見出しと説明的な文章は出力言語設定に従います。技術的識別子（SHA、ファイルパス、ゲート名、発見id）はそのまま保持されます。

Mediumおよびhigh努力のレビューは、同じステムを持つ構造化JSONコンパニオンも保存します（例: 2026-04-06-143022-pr-123.json）。これには正規化された発見と構成された判定がデータとして含まれます。Qwen CodeのWeb Shellはそのドキュメントをフィルタリング可能な発見を持つインタラクティブなレビュービューとしてレンダリングします。Markdownレポートは人間が読めるアーカイブとして残ります。

パイプラインの決定的な部分 — 引数解析（qwen review parse-args）とイベント/ボディの決定（qwen review compose-review）— はプロンプトテキストではなくテストされたサブコマンドです。そのため、--effort の文法、--comment の強制、判定キャップ、ダウングレードの動作はユニットテストで固定されており、モデルによってずれることはありません。

GitHub Enterprise: github.com 以外のホストのPR URLをレビューする場合、そのホストのすべてのGitHub呼び出しがルーティングされます。レビューサブコマンド（match-remote、meta、fetch-pr、pr-context、comment-status、issue-context、fetch-diff、comment-body、plan-diff、test-plan、presubmit、compose-review、submit、publish-assets）は --host を受け取り、コード内で設定します。そのため、ホストの忘れによってレビューがサイレントに github.com にリターゲットされることはありません。

Aone Code: オリジンが gitlab.alibaba-inc.com 上にあるクローンをレビューする場合、そのクローン内から /review を実行します。プラットフォームがリモートから検出され、サブコマンドは a1 CLI に基づいて動作します（少なくとも0.1.90 — 古いインストールは認証時にアップグレードメッセージとともに拒否されます）。ターゲット番号はグローバル MR ID です。fetch-pr は refs/merge-requests/<id>/head をフェッチして worktree + diff を構築するため、worktree のエージェントレビューは変更されません。test-plan もバックイングされています — 同じリーダーを通じてMR説明を読み取ります。pr-context もバックイングされています。MRのメタデータ、ディスカッションスレッド、および以前投稿された qwen サマリーを読み取ります（マシンレジャーはそこから回復します）。そのため、Aone の実行は MR の既存のディスカッションを、GitHub の実行が PR の既存ディスカッションを見るのと同じように確認できます。comment-status と presubmit も a1 でバックイングされています（presubmit は完全に: セルフPR検出、ヘッドドリフト、マージゲートCI、既存コメントの重複排除）。そのため、繰り返しの --comment ラウンドは MR の既存コメントに対して重複排除されます（プラットフォームが古いとマークしたスレッド — 修正後に行がマッピングされなくなったもの — は再投稿可能です）。セルフPR検出も機能します。publish-assets の書き込みはスキップされます。--comment は a1 CLI を通じてレビューを投稿します。インラインの発見ごとに1つのコメント、その後サマリーコメントです。Aone にはネイティブの request-changes 状態がないため、その判定ではサマリーコメントにブロッキングヘッダーが付き、実際に投稿されたインライン Critical はディスカッションゲートを通じてマージをブロックします（ディスカッションが未解決のまま）。インライン Critical が投稿されていない場合、ヘッダーは助言的なもので、機械的にマージをブロックするものはありません。投稿されたコメントには AI コメントフラグが含まれません — a1 は設定できないため、リポジトリ専用の ai_comment マージゲートはこれらを追跡しません。ネイティブの a1 repo mr approve は、実行が MR のコンテキストを読み取った場合に Approve 判定に対して発火します（GitHub と同じゲート。コンテキスト利用不可の実行は Comment にキャップされます）。インクリメンタル再レビューは AGit-Flow の更新モデルに従います。更新は単一の CR コミットをその場で AMEND し、前のラウンドがレビューしたヘッドを孤立させます。そのため、キャッシュされたアンカーは血統なし（WITHOUT ancestry）でルールされ（anchor-behind-head テストはすべての更新で失敗します）、再レビューは PR 自身の diff を更新が触れたファイルにスコープし、全体レビューにフォールバックしません。新しいマスターにリベースも行った更新は、リベースのドリフトが CR のファイル内に留まる限りそのスコープを保持します。他のファイルに触れるドリフトは全体レビューにフォールバックし、いずれの場合もドリフトのバイトは公開されたスコープに入りません。docs/design/2026-08-15-review-aone-provider.md を参照してください。

すべての実行は1つの機械可読行で終わります（Review complete: <target> — <disposition>）。スクリプトとCIラッパーは単一の ^Review complete: マッチで完了と結果を検出できます。

ヘッドレス実行（qwen review run）

/review はインタラクティブです。スクリプトやCIジョブがレビューを実行し、その結果に基づいてアクションを行う場合は、ヘッドレスラッパーを使用します。

qwen review run [target] [--json] [--fail-on request-changes] [--comment] [--resume] [--quiet]

target はPR番号、PR URL、またはファイルパスです。省略するとローカルワーキングツリーをレビューします。このコマンドは自身のCLIのビルドを非対話的に実行し（stdinを閉じた状態で、スラッシュコマンド検出が生き残ります）、子プロセスの進捗をstderrにストリーミングし、判定をstdoutに出力します。または --json で完全な結果オブジェクトを出力します。判定は compose-review が書き出す成果物から読み取られます（スキルが判定の権威として扱うJSONと同じ）。モデルの文章から解析されることはありません。

終了コードはゲートが読むべき契約です。

3（2ではなく）により、ゲートは出力を解析せずに「レビューがブロックしている」と「ツールが壊れた」を区別できます。yargsはすでに1を使用エラーに使用しています。--timeout-minutes（デフォルト120、1以上に設定）はハングしたレビューを終了し1で終了します。コマンドのキャンセル（Ctrl+C / SIGTERM）はレビューのプロセスグループを終了し、孤立させません。

--resume は、最初からやり直すのではなく、同じPRの中断されたレビューを続行します。長時間のローカル実行が途中で終了した場合（接続の切断、タイムアウト、キルされたターミナル）、再試行はそうでなければ、すでにディスク上にある作業を行うエージェントの再フェッチ、再チャンク、再起動を行います。再試行時に無条件で安全に渡せます。fetch-pr はディスク上の状態自体（フェッチされたSHAのworktreeがまだ存在してクリーン、diffバイトが変更されていない、PRヘッドが移動していない、再開キャップが未消費）をチェックし、一致しないものがあればサイレントに新しいレビューにフォールバックするため、このフラグが最初から始められる実行を失敗させることはありません。続行は中断された実行の記録された努力レベルに固定されます。明示的に異なる --effort を渡すと再開を拒否し、要求されたレベルで新しく実行します。PRターゲットのみ（ローカルレビューのdiffはライブのワーキングツリーからキャプチャされ、続行するための安定した中断状態がありません）。再開はローカルの利便性です。リポジトリ独自のCIレビューワークフローは再開しません。各再試行は新しく再実行されます。CIの実行はノーサンドボックスで実行され、終了時にworktreeが削除されるため、続行可能な中断状態は残りません。

時間制約のある実行は、ソフトデッドラインもエクスポートできます。レビューがまだ検証、構成、投稿の時間がある間に、オープンエンドの逆監査ループを停止するようにします。QWEN_REVIEW_DEADLINE_EPOCH は実行がキルされるUnix秒の瞬間であり、QWEN_REVIEW_DEADLINE_RESERVE_SECONDS（デフォルト3600。0 はラウンド推定のみを保持）は最後のラウンドの検証、compose-review、提出のために残っている必要があるテールです。残りの予算が別のラウンドとそのテールに収まらない場合、ラウンドビルダーはそれを構築することを拒否し、構成された判定は切り詰められた監査を開示します（Approveの判定はCommentにキャップされます）。欠落または不正なデッドラインはレビューをゲーティングなしのままにします。外部のタイムアウトが引き続き実行を制限します。

そのリザーブの内側には、より小さなコンポーズフロア QWEN_REVIEW_DEADLINE_COMPOSE_FLOOR_SECONDS（デフォルト1200。0 はこのゲートを、デッドライン通過後を含むすべての時点で完全に無効化します）があります。リザーブは「最後のラウンドの検証 ＋ 構成 ＋ 提出」をカバーする1つの数値であり、通常の発見ごとの再トレースには収まりますが、検証がファイルシステム/git ワークロードを制限なく再実行するセキュリティレビューには収まりません。そのため、検証器（ラウンドビルダーではなく）がこのフロアでゲーティングされます。フロア以下しか残っていない場合、agent-prompt --role verify は構築を拒否し（VERIFY BUDGET: 行、終了コード 4）、手元にある発見は未検証タグを保持し（これが判定をキャップします）、compose-review と提出が実行されます。フロアはリザーブより厳密に下にあるため、正常な実行では最初に逆監査ゲートに到達し、ここには到達しません。リザーブがバウンドできない唯一の区間をカバーするものです。

クロスファイル影響分析

専用クロスファイルトレーサー（Agent 1c）がこのウォークをエンドツーエンドで担当します。コードの変更によってエクスポートされた関数、クラス、またはインターフェースが変更された場合、すべての呼び出し元を検索し、互換性をチェックします。

• パラメータ数/型の変更
• 戻り値型の変更
• 削除または名前変更されたパブリックメソッド
• 破壊的な API 変更

プロデューサー方向も辿ります。diffが追加する各フィールド、オプション、またはオプションパラメータは、その読み取りサイトまで追跡されます。diffが触れないファイルも含みます。何も設定していないフィールドをライブコードパスが読み取っている場合、それがゲートする機能はサイレントに何もしません。これは読み取りサイトでCriticalとしてフラグが立てられます。

大きなdiff（>10個の変更されたシンボル）の場合、呼び出し元方向の分析はシグネチャが変更された関数を優先します。プロデューサー方向は予算制限されません。変更されていないシグネチャがまさにそのポイントだからです。

レビューバジェット

パイプラインのdiffサイズに対して弾力的な部分はそれからスケーリングされ、スケーリングはdiffプランに書き込まれるため、すべてのステージが1つの数値を読み取り、それぞれが独自に決定することはありません。

意図的に行わないことが2つあります。次元をスケールオフしません。レビューが提供するエージェントはrosterによって決定され、rosterは努力レベルを読み取ります。そのため、小さなdiffでもセキュリティパスとテストカバレッジパスを受け取ります。そして、diff行ではなくソース行を読み取ります。900行の新規テストを出荷する40行の本番変更は小さな変更です。同じ推論がすでにテリトリーファンアウトゲートを支配しています。

フロアが現在値にある理由: 9行のタイプミス修正では、6つのインラインウォークは5つの無駄なウォークであり、スイープ（1回目のパスが届かなかったものを探す新しいリーダー）は、1回目のパスがすべてに届いたときには探すものがありません。Agent 8のフロアは実質的なものです。「1つのドメインがdiffを支配している」は判断であり、40行について行われる判断は、40行が通常1つのことであるため、常に支配的なドメインを見つけます。

トークン効率

高努力パイプラインは各ステージをバウンドします（シャードサイズ、監査ラウンド）が、合計呼び出しは発見数に応じてスケールします（ceil(F/8) 検証シャード）。3Bではチャンク数に応じてスケールします（逆監査はラウンドごとにチャンクごとに実行）。典型的な3Aプロファイル:

ほとんどのPRは範囲の下限に収束します。キャップは異常なケースでのコストの暴走を防ぎます。--effort low ではレビューは完全にインラインで実行されます。0サブエージェント呼び出しで、全体を1回ではなく角度ごとに1回diffを歩きます。

フラグが立てられないもの

レビューでは意図的に以下のものを除外しています。

• 変更されていないコードの既存の問題（差分のみに焦点を当てる）
• フォーマッタが自動的に正規化するスタイルやフォーマット、またはコードベースの規約に合致する命名 — ただし、リンタや型チェッカがフラグを立てるような実質的な問題（未使用の変数、到達不能なコード、型エラー）は対象内
• 実際の問題がない場合の主観的な「X を検討してください」といった提案
• バグやリスクを修正しない軽微なリファクタリング
• ロジックが本質的に理解が困難な場合を除き、ドキュメントの欠落
• 既存の PR コメントですでに議論された問題（人間のフィードバックの重複を避ける）

設計思想

沈黙はノイズに勝る。 すべてのコメントは、読み手の時間を割く価値があるものでなければなりません。

• 問題かどうか確信が持てない場合 → 報告しない
• すべての発見は具体的な失敗シナリオ（トリガー → 誤った結果）または具体的なコストを名指しします。それができない発見はあなたに届く前に削除されます
• N 個のファイルに同じパターンがある場合 → 1 つの発見に集約
• PR コメントは高い確信度のみ（かつ高努力の検証済みレビューからのみ）
• コードベースの規約に合致する表面的なスタイル/フォーマットは除外