自動化の挙動

Chorus プラグインを接続すると、AI-DLC ワークフローで既におなじみのワークフローに、いくつかの挙動が上乗せされます。適切なタイミングで独立したレビューを促し、手作業で管理しなくてもエージェントのセッションを追跡し、無人のエージェントができることを制約します。このページではそれらの挙動を説明します。ライフサイクルの各段階や、ランタイムのインストール・起動・復旧の方法は繰り返しません。それらはそれぞれ AI-DLC ワークフロー、 Chorus デーモンを運用する、セッションを中断して再開する、そしてエージェントプラットフォームを参照してください。

Hermes の自動化

Hermes はネイティブフックでチェックインと仕様モードを注入し、提案送信、タスク検証依頼、最終タスク検証後にレビューを促します。親は delegate_task に [chorus-reviewer:proposal]、[chorus-reviewer:task]、[chorus-reviewer:code] のマーカーを付け、対応スキルを読み込みます。子は読み取りと判定コメントのみ可能で、端末実行、編集、再委派はできません。ゲートウェイのコマンド承認は Chorus コメントで所有者に送ります。approvals.mode manual と security.approval.transport chorus を使い、対話セッションは設定した builtin にフォールバックします。以下の Claude daemon のヘッドレス制限とは別です。

レビュー担当サブエージェント

プラグインは、パイプラインの 3 つの節目に独立した品質ゲートを加えます。各節目で PostToolUse フックが発火し、メインエージェントに専用の読み取り専用のレビュー担当サブエージェントの起動を促すリマインダーを注入します。レビュー担当は自動では起動しません。メインエージェントが起動し、実行環境の完了待機機構で待ってから、今回の裁定コメントを読みます。完了したレビューは PASS、PASS WITH NOTES、または FAIL の裁定を投稿します。

PASS / PASS WITH NOTES — 作業は続行します。メモは参考情報です。
FAIL — 列挙されたブロッカーを修正し、作業を再提出してからでないと先に進めません。

レビュー担当は作業を変更せず、検査します。Proposal reviewer は ls、rg、find、git log/show/diff などの読み取り専用シェルコマンドを使えます。パスが存在しないと報告する前に、必ず確認します。ファイル変更、 Git の書き込み操作、依存関係のインストール、テスト/ビルドの実行は禁止です。Task reviewer と code reviewer はさらに、プロジェクト自身のテスト・ビルド・lint コマンドも実行できます。これは Kiro を含むすべての環境で同じで、Kiro ではブロックするコマンドの一覧によって、ファイル変更、Git の書き込み、インストールが止められます。

レビュー担当	発火のタイミング	レビュー対象	裁定の投稿先
Proposal reviewer	`chorus_pm_submit_proposal` の後	文書の完全性、課題の粒度、受け入れ基準との対応、そして依存グラフ	提案
Task reviewer	`chorus_submit_for_verify` の後	その課題の実装が受け入れ基準と提案文書を満たしているか。加えて、どの受け入れ基準も触れていない場合にも適用される既定の品質チェック：正しさ、既存のものの再実装、その課題自身のコードにあるセキュリティホール、失敗しえないテスト、必須の操作の失敗が黙って握りつぶされていないか	課題
Code reviewer	着想を根とする提案の最後の課題が検証されたとき（`chorus_admin_verify_task`）	その着想の全課題にわたる集約的な変更 — 課題間の統合、アーキテクチャの逸脱、セキュリティ、リグレッション、機能レベルのカバレッジ	着想

Code reviewer は出荷前の最終ゲートです。着想を根とする提案の最後の課題が検証されたときにのみ実行され、単一の課題ではなく機能全体を一度にレビューします。

ラウンドをまたいで指摘を追う

すべての指摘には安定した ID が付きます。ブロッカーは B<round>-<slug>、メモは N<round>-<slug> で、 round はその指摘を最初に報告したラウンドです（例：B1-ac3-not-implemented）。ID は変わらないので、ラウンド 3 の裁定に B1-… の行があれば、その問題が 2 回の修正を経ても残っていることがわかります。ラウンド 2 以降、レビュー担当は過去の指摘をすべて Prior findings の下に列挙し、fixed、still-open、 not-verifiable の 3 つの状態のいずれかと、判断のために何を再実行したかを添えます。指摘を閉じるのは fixed だけです。未解決のまま、または再検証できなかったブロッカーがあれば、裁定は FAIL のままです。未解決のメモがあっても、裁定が PASS WITH NOTES より悪くなることはありません。

裁定に長さの上限はなく、ブロッカーの根拠は省略せずに書きます。その代わり、最初のラウンドで報告するメモは最大 5 件で、以降のラウンドでは新しいメモを加えません。こうして各コメントは、対応が必要なことに絞られます。

今回の裁定を待つ

Claude Code ではレビュー担当の完了通知を待ちます。フォアグラウンド起動を要求しても、起動結果は裁定ではありません。Codex ではネイティブの起動・待機機構を使います。Pi 同梱の subagent ツールはレビュー担当が戻るまでブロックします。どの環境でも、過去のラウンドではなく、今回の起動後に投稿された VERDICT: コメントを読んでください。

新しい裁定がなければ、無応答と明示的な引き継ぎを区別します。

明示的なレビュー拒否やラウンド上限の通知：停止し、人間の判断に委ねます。再起動や自己レビューでこの引き継ぎを置き換えてはいけません。
まったく応答がない場合：1 回だけ再試行します。再試行でも明示的な拒否がないか確認します。2 回目も完全に無応答の場合に限り、メインエージェントが読み取り専用の自己レビューを行い、裁定を投稿できます。無応答を合格と扱ってはいけません。

元の意図との整合性を確認する

3 つのレビュー担当は、元の着想の本文、人間が回答した要件詳細化、人間が書いたコメントとも照合します。エージェントのコメントやエージェントが回答した要件詳細化は監査用の文脈であり、スコープ変更の承認にはなりません。

スコープの追加、要件の欠落、受け入れ基準には合格しても元の要件を満たさない変更は、人間のコメント・回答や明示的な上書き判断を引用して承認を示せない限り、ブロッカーです。Proposal reviewer は計画、task reviewer は実装、code reviewer は機能全体を確認します。

レビュー担当をオン・オフする

これらのレビュー担当は、プラグインのインストールや設定時に調整できる userConfig 設定で制御されます。各レビュー担当にはオン/オフのトグル（すべて既定でオン）と、人間へエスカレーションする前に「レビュー・修正」ループを何回まで走らせるかを制限する最大ラウンド上限があります。

設定項目	型	既定値	効果
`enableProposalReviewer`	boolean	`true`	提案の提出後に proposal reviewer の起動を促す
`enableTaskReviewer`	boolean	`true`	課題を検証に提出した後に task reviewer の起動を促す
`enableCodeReviewer`	boolean	`true`	着想の最後の課題が検証された後に code reviewer の起動を促す
`maxProposalReviewRounds`	number	`3`	人間へエスカレーションする前の最大提案レビュー・修正ラウンド数（`0` = 無制限）
`maxTaskReviewRounds`	number	`3`	エスカレーション前の最大課題レビューラウンド数（`0` = 無制限）
`maxCodeReviewRounds`	number	`3`	エスカレーション前の最大コードレビューラウンド数（`0` = 無制限）

あるレビュー担当をオフにすると、その独立した品質チェックは失われますが、トークン消費は減ります。別の enableOpenSpec トグルが OpenSpec モードを制御しますが、これは専用のページで扱います。

セッションライフサイクルフック

2 つ目のフック群は、エージェントの Chorus セッションを自動的に管理します。そのため、あなたもエージェントも、セッションを手作業で開いたり、ハートビートを送ったり、閉じたりする必要はありません。これらは判断も促しも伴わず、自動的に動作します。

SessionStart — 接続性をチェックし、エージェントをチェックインし、プラグインが事前に作成したセッションがあれば見つけ出します。
SubagentStart — ワーカーの開始前に、そのワーカーのエージェントの種類にちなんだ名前の Chorus セッションを作成または再利用します。同じ種類のワーカーはセッションを共有できます。
SubagentStop — 終了するワーカーによるセッションの保持を解除します。課題の自動チェックアウト、セッションのクローズ、条件を満たす場合の自動検証は、そのセッションを共有する最後のワーカーが終了するまで待ってから行われます。
ハートビートとリマインダー — 待機中のワーカーはハートビートを送り、長時間の実行中にセッションが非アクティブと見なされないようにします。PostToolUse リマインダーは、上記のレビューの節目でメインエージェントを促します。

これらのフックがセッションのライフサイクルを掌握しているため、エージェントは自分でセッションを作成したり閉じたりしてはいけません。これらのセッションが動くランタイムそのものの管理（起動、作業ディレクトリの選択、中断、再開）については、Chorus デーモンを運用するとセッションを中断して再開するを参照してください。

ヘッドレスなデーモンセッション：対話プロンプト禁止

エージェントがデーモンセッションとして無人で動くとき、ポップアップに答える人間は端末の前にいません。ヘッドレスなセッションは、判断に到達するために対話プロンプト（AskUserQuestion など）を使ってはいけません — 誰も答えられないプロンプトは、実行全体を止めてしまいます。

代わりに、エージェントはあらゆる判断を Chorus 経由で人間に戻し、責任を持つ人間が非同期に応答できるようにします。

課題や提案に根拠を十分に示したコメントを投稿し、必要な正確なアクション（例えば管理者による検証）を添えて責任者を @mention します。
ライブの回答を待って止まる代わりに、要件詳細化を使って着想上の未解決の疑問を記録します。

これにより監査証跡は保たれ、人間は次に Chorus に入ったときに応答できます。セッションが表に出せないプロンプトで待たされることもありません。この引き渡しはセッションが対話式でもヘッドレスでも同様に適用されます。対話プロンプトが使えないのはヘッドレスの場合だけです。

Codex の違い

Codex プラグインは移植版であり、完全な鏡像ではありません。Codex は Claude Code と同じ 3 つのレビュー担当（proposal、task、code）を走らせ、それぞれ提案の提出後、課題を検証に提出した後、そして着想を根とする提案の最後の課題が検証された後に、同じ PostToolUse / フックの促しで起動されます。違うのはレビュー担当の顔ぶれではなく、設定と起動の仕組みです。

userConfig のトグル設定がない。 Codex は enable* のレビュースイッチもラウンド上限の設定も公開しません。レビューの促しは Codex のスキルとフックが直接駆動するため、Claude Code のようにインストール時にオフにはできません。例えばコードレビューの促しは既定でオンで、無効化するトグルがありません。
ネイティブな起動。 メインエージェントは Claude Code の Agent Teams ではなく、Codex 自前の spawn_agent / wait_agent を通じてレビュー担当を呼び出します。また TeammateIdle や TaskCompleted フックに相当するものは Codex にはありません。

OpenClaw、Kiro、Pi のランタイムでは、自動化の挙動が Claude Code と異なる場合があります。Claude Code の挙動をそのまま前提とするのではなく、エージェントプラットフォーム下の各ランタイムのページで、何がサポートされているかを確認してください。

エージェント向け

トリガー:
- chorus_pm_submit_proposal の後、PostToolUse フックが chorus:proposal-reviewer の起動を促します。完了を待ち、提案上の今回の VERDICT: コメントを読みます。
- chorus_submit_for_verify の後、chorus:task-reviewer を起動します。課題上の VERDICT: コメントを読みます。
- 着想を根とする提案の最後の課題に対して chorus_admin_verify_task を行った後、code reviewer を起動します。着想上の VERDICT: コメントを読みます。これは Claude Code（chorus:code-reviewer）と Codex（chorus-code-reviewer）の両方で動きます。
- レビュー担当は自動では起動しません。あなた自身が起動し、裁定を待ちます。PASS / PASS WITH NOTES は続行、FAIL はブロッカーを修正して再提出を意味します。
制約:
- 上記の読み取り専用の制限と今回の裁定の待機規則に従います。提案レビューではシェル検査は可能ですが、テスト/ビルドは禁止です。人間への明示的なエスカレーションを再起動や自己レビューで回避してはいけません。
- 3 つのレビュー担当（proposal、task、code）すべてが Claude Code と Codex の両方に搭載されています。Claude Code 限定なのは userConfig のトグル設定、つまり enable* スイッチ（enableProposalReviewer、enableTaskReviewer、enableCodeReviewer）とラウンド上限（maxProposalReviewRounds、maxTaskReviewRounds、maxCodeReviewRounds、既定 3、0 = 無制限）です。Codex には userConfig がないため、Codex 上ではこれらのレビュー担当はスキルとフックが直接制御し、インストール時にオフにはできません。
- chorus_create_session や chorus_close_session を呼び出さないでください。セッションライフサイクルフック（SessionStart、SubagentStart、SubagentStop）が管理します。
- ヘッドレスなデーモンセッションは対話プロンプト（AskUserQuestion など）を使ってはいけません。判断は Chorus のコメント + @mention と要件詳細化を通じて差し戻してください。