コードレビュー
Agent Teams のコードレビューはタスク中心です。大きな構造化されていない差分を探し回るのではなく、特定のタスクで何が変更されたかを確認します。
レビュー画面
ファイルに変更があった完了済みタスクごとに、レビュー UI では次のことができます。
- 変更前後のコンテキスト付きで変更されたファイルを確認する
- 個々のハンクを承認または却下する
- インラインコメントを残す
- 差分をタスクの説明やエージェントのログと結びつける
ハンク単位の判断
正しい小さな変更は承認し、孤立したミスはタスク全体を捨てることなく却下できます。これは、エージェントがおおむねタスクを解決したものの、1 つのファイルでやりすぎてしまった場合に便利です。
段階的に承認する
差分がおおむね正しい場合は、まず良いハンクを承認し、修正が必要な部分についてのみ変更をリクエストしてください。これによってボードが滞りなく進みます。
ハンク単位の判断は次の場面で使います。
| 状況 | アクション |
|---|---|
| 正しく範囲が絞られた変更 | ハンクを承認する |
| 考え方は正しいが、ファイルが違うか広範なリファクタリング | ハンクを却下し、より範囲を絞った修正をリクエストする |
| 不明瞭な挙動の変更 | コメントして検証を求める |
| 生成されたフォーマットのノイズ | フォーマットがタスクの一部でない限り却下する |
レビューの開始
- 完了済みのタスクを開く
- Changes タブを見る
- 差分が妥当に見えたら、Request Review をクリックしてタスクを review 列に移動する
レビュー中、タスクはまだ done とはみなされないため、他のチームメイトやリードはまだコメントできます。
レビューループ
健全なレビューループは次のようになります。
- オーナーが変更範囲と検証内容を記載した結果コメントを投稿する
- レビュアーがタスクの差分を開き、タスクの説明と照らし合わせてハンクを確認する
- レビュアーが良いハンクを承認し、悪いハンクを却下するか、変更をリクエストする
- オーナーがリクエストされた範囲のみを修正し、フォローアップのコメントを投稿する
- タスクの結果と差分が一致したら、レビュアーが承認する
変更リクエストのコメント例:
Please keep the copy improvements, but revert the unrelated runtime wording in the provider table. Add the `pnpm --dir landing docs:build` result before resubmitting.レビュー状態
| 状態 | 意味 |
|---|---|
none | タスクが新規、in progress、または完了済みだがまだレビュー中ではない |
review | タスクがアクティブにレビュー中である |
needsFix | 変更がリクエストされた。オーナーは再承認の前に更新する必要がある |
approved | レビューが承認され、タスクが確定した |
エージェントによるレビューのワークフロー
チームは、あなたが最終判断を下す前にお互いの作業をレビューできます。これによって明らかなリグレッションを検出し、ボードを健全に保てますが、リスクの高い領域は依然として自分自身でレビューすべきです。
エージェントによるレビューは、レビュアーが明確な基準を持っているときに最も役立ちます。たとえば、ドキュメントの明瞭さのみ、IPC の安全性のみ、あるいはテストカバレッジのみを確認するようレビュアーに指示します。漠然とした「すべてをレビューして」というリクエストは、弱いフィードバックになりがちです。
MCP 駆動のレビュー状態
レビュー状態の変更（レビューのリクエスト、変更のリクエスト、承認）はツール駆動です。タスクに「変更をリクエスト」のコメントを残しても、かんばんの列は needsFix に移動しません。リードまたはエージェントが適切な MCP ツールを呼び出す必要があります。
review_request_changes— タスクをneedsFixに移動し、オーナーに通知するreview_approve— タスクをapprovedに移動し、レビューを確定する
コメントだけでは状態遷移には不十分です。レビュー用 MCP ツールの完全な一覧とそのパラメーターについては、MCP 連携を参照してください。
レビューの参加者
チームリードがデフォルトのレビュアーです。仲間同士でお互いの作業をレビューさせたい場合は、かんばん設定で追加のレビュアーを設定できます。
手動で確認すべきこと
レビューの際は次の領域を優先してください。
- プロバイダー認証とランタイム検出 — エージェントは他のパスを壊すような形でランタイムのセットアップを変更していないか？
- IPC、preload、ファイルシステムの境界 — Electron の責務を分離したままにする
- Git と worktree の挙動 - ブランチの命名、コミット、プッシュを検証する。分離のパターンについては Git と worktree の戦略を参照してください。
- パースとタスクライフサイクルのロジック — タスク参照、チャンク化、フィルタリングへの変更はメッセージ配信を壊す可能性がある
- 永続化とコードレビューのフロー — タスクストレージやレビュー状態への変更は IPC レイヤー全体で一貫している必要がある
正規の機能レイアウトとハードガードレールへのリンクについては、コントリビューター向けアーキテクチャを使用してください。
検証
範囲を絞った検証コマンドを優先してください。広範なフォーマットや lint-fix コマンドは、タスクが明示的に広範なフォーマットの変更を意図している場合を除き、使用すべきではありません。
良い検証コメントにはコマンドと結果が含まれます。
Verified with `pnpm --dir landing docs:build`. Build passed.検証を省略する場合は、その理由をタスクのコメントに記載すべきです。
Docs-only wording change. Build not run because the existing dev server was busy; checked Markdown links manually.プロジェクト全体に対する自動フォーマットは行わない
タスクが特にフォーマットに関するものでない限り、無関係なファイルに対して pnpm lint:fix を実行するのは避けてください。レビュー画面にノイズを生み出します。