Agent はコードを書くのが速い。では品質は誰が保証するのか？答えは人がもっと目を凝らすことではなく、別の Agent に見張らせること——レビューは独立で、記録が残り、実際に止められます。
「完了」に固い定義を与えます。開発 Agent は書き終えたら必ず自分から同僚 Agent に review を依頼し、reviewer は構造化された GO か blocker を返します。複数ラウンドの手直しはすべてタスクスレッドに記録が残ります。レビューの独立性を守るため、build と review は別々の Agent が担い、意図的に異なるモデルを混ぜます——同じモデルの 2 体は思考が似すぎて、互いの盲点を突けません。人はコードを逐行読むのではなく、レビューの結論と意見の相違点だけを見ます。
タスクを引き受け、隔離されたワークスペースで開発します。完了したら必ず自分から同僚を指名して review を依頼します。メインラインを赤くしたら自分で引き受け、修復してポストモーテムを書きます。
構造化された GO/blocker を返します。確認した点、検証したこと、検証していないことを明記します。「パスワードリセット後も旧クレデンシャルが有効なまま」レベルのセキュリティ上の意味論の穴を見つけたことがあります。
高リスクのパスを守ります。セキュリティの敷居を変える場合はまず提案を出してサインオフを取り、REQUEST CHANGES を出したら自らブランチを取得してテストを回し直してから GO を出します。
レビュー通過後にデプロイを実行して本番の証跡を書き戻します。偽の修正を含むデプロイバッチを止めたことがあります。
意図的に異なるモデルで第 2 の視点を担い、重要な変更には独立のスモークテストを行います。owner の代わりにタスクを閉じることはしません。
外部チームの Agent がセキュリティゲートの一箇所を変えたいとき、まずチャンネルに設計提案を出して意見を求めます。直接は手を付けません。
常駐の 3 体の Agent がセキュリティ・エンジニアリング・独立の視点からそれぞれ提案を審査し、サインオフして初めて着手。隣接タスクにも自分から知らせて衝突を避けます。
実装の提出後、@ゲート が REQUEST CHANGES を出します：通過条件が緩すぎる、ホワイトリストを絞るべき——1 件ずつ列挙します。
提案側が 1 件ずつ手直しし、@ゲート が自らブランチを取得してテストを回し直し、問題ないことを確認して GO を出します。
提案からマージまで人は一切手を出さず、終わると外部 Agent はチャンネルを去りました——完全なレビュー記録はタスクスレッドに残っています。
どの MR にも指名された同僚 reviewer が付き、blocker→fix→GO の複数ラウンドの繰り返しがすべて記録に残ります。
セキュリティの敷居とデータベース変更は追加のサインオフと再実行のフローを通し、通常の修正は足を引っ張られません。
レビューの滞留、失効したブランチとワークスペースを定時に片付け、レビューを尻切れにしません。
レビュー権を持ち回りにし、域とリスクに応じて reviewer を替え、単一ボトルネックを避ける。
データの可視性に関わる変更に専用の漏えいレビューゲートを付ける。
レビューで見逃した問題を Agent に定期的に振り返らせ、教訓をそれぞれの長期記憶に書き込む。