recursive-subagent

recursive-subagent

再帰モードのフェーズでサブエージェントが役立つかを判断し、使用する場合は引き継ぎの契約を遵守するために、このスキルを使用します。

このスキルによって、正規のワークフローが緩和されることはありません。メインエージェントは、引き続き次の責任を負います。

• 一度にアクティブにする再帰フェーズは1つだけにする
• ユーザーが現在やり取りしている唯一のオーケストレーターとして対応する
• ロック前に徹底的な監査を行う
• 不完全、または文脈を欠いたサブエージェントの出力を却下する
• サブエージェントを利用できない場合は self-audit に切り替える

recursive-router がインストールされている場合、ユーザーがルーティングの使用を明示的に求めているとき、または選択された委任先の役割に対してアクティブな外部ルートが設定されているときは、これを参照します。ルーターの検出や設定によってデバイス上のローカル CLI やプロバイダーの設定が調査される場合があるため、新たなセットアップやポリシー変更を行う前に、ユーザーに確認してください。現在ディスパッチする必要がある役割に、すでに設定済みの外部ルートを適用するだけの場合は、再確認する必要はありません。

ユーザーがルーティング設定を承認した場合、ルーティングによる委任を明示的に要求した場合、または役割にアクティブな外部ルートが設定されている場合は、その役割に対するルーティング先の外部 CLI／モデル経路を選択する前に、次を参照します。

• /.recursive/config/recursive-router.json
• /.recursive/config/recursive-router-discovered.json
• ../recursive-router/SKILL.md

ルーティングによるディスパッチを行う直前に、毎回これらのファイルをディスクから読み直してください。実行中にポリシー、検出状態、またはフォールバック動作が変わっている可能性がある場合、以前のメモリー内の解決結果を再利用してはいけません。recursive-router-resolve が external-cli を返す場合、その委任スロットには recursive-router-invoke を使用します。ローカル実行／セルフ監査が有効な経路となるのは、ルートが fallback-local、local-only、blocked、または ask-user に解決された場合のみであり、その旨を記録した成果物を残す必要があります。

使用の優先順位

サブエージェントは、次の優先順位で使用します。

1. アナリスト
2. プランナー
3. コードレビュアー
4. メモリー監査担当
5. テスター
6. 実装担当者（書き込み範囲が真に分離されている場合）

サブエージェントを必須のインフラストラクチャとして扱わないでください。任意のインフラストラクチャですが、サブエージェントが利用可能で、コンテキストバンドルが完全な場合は、監査／レビューを委任することを既定の優先選択とします。

能力の検出は重要な制御ポイントです

委任を検討するフェーズの開始時に、その環境が実際にサブエージェント／タスクに対応しているかどうかを判断します。

サブエージェントを利用できない場合：

• Subagent Availability: unavailable を記録する
• Audit Execution Mode: self-audit を記録する
• 同じ監査をローカルで実施する

サブエージェントを利用できる場合：

• Subagent Availability: available を記録する
• コンテキストバンドルが完全であれば、監査／レビュー作業は既定で委任する
• 現在のタスクがルーティングによる委任を明示的に求めている場合、または選択された役割に外部 CLI ルーティングが設定されている場合は、ディスパッチ前にルーターポリシーを参照する
• コントローラーが引き続き self-audit を選択する場合は、具体的な Delegation Override Reason を記録する
• 同じ監査チェックリストと合格基準を適用する

委任する前に、/.recursive/memory/skills/SKILLS.md と、委任レビュー、レビュー用バンドルの適合性、古いコンテキストに伴うリスクに関係するスキルメモリーのシャードを読みます。

委任できないことを理由に、監査を省略したり、基準を緩めたりしてはいけません。

正規の制約

• 再帰フェーズは順次実行します。1回の実行でアクティブにできるフェーズは必ず1つです。
• サブエージェントはアクティブなフェーズ内で支援できますが、並行したフェーズ作業を許可するものではありません。
• 書き込み可能な実装を並行して行えるのは、明示的に独立したサブフェーズで、書き込み範囲が分離されており、依存関係によるブロックの連鎖がない場合に限られます。
• 監査、レビュー、読み取り専用の検証を、委任する作業の最も安全な既定の選択とします。

委任監査の契約

委任監査が有効なのは、コントローラーが完全なコンテキスト一式を渡した場合に限られます。引き継ぎを永続的かつ再現可能にするため、/.recursive/run/<run-id>/evidence/review-bundles/ 以下の標準レビューバンドルファイルを使用することを推奨します。

コントローラーは、以下のすべてを渡す必要があります。

1. フェーズ名と成果物のパス
2. 現在のフェーズのドラフト
3. 再読が必須の正確な上流成果物パス
4. 関連する追補のパス
5. 関連する過去の再帰的証拠とメモリー参照
6. 00-worktree.md に基づく差分の基準
7. 変更されたファイルの一覧
8. 調査対象となるコードファイルのパス、またはファイルグループ
9. 必要に応じた関連するコントロールプレーンのドキュメント
10. フェーズに関する正確な監査質問／チェックリスト
11. 所見と判定を含む、必須の出力形式

「このフェーズをレビューしてください」や「実装を監査してください」といった曖昧な委任は無効です。

必須項目に不足がある場合は、委任せず、自分で監査してください。

修正によってレビュー対象の範囲、変更ファイル、または証拠が大きく変わる場合は、再監査の前にバンドルを更新してください。

コントローラーのチェックリスト

ディスパッチ前：

• 委任は任意であり、必須ではないことを確認する
• そのフェーズが引き続き唯一のアクティブフェーズであることを確認する
• 引き継ぎバンドルが完全であることを確認する
• フェーズの成果物に委任を記録する場合、標準レビューバンドルのパスが存在することを確認する
• 永続的なサブエージェントアクション記録が /.recursive/run/<run-id>/subagents/ 以下に書き込まれることを確認する
• 初期プロンプトバンドルがプロンプトバンドルのパスから参照され、ルーティングされたアシスタントの出力、stdout／stderr のトランスクリプト、呼び出しメタデータが subagents/ 直下ではなく /.recursive/run/<run-id>/evidence/router/ 以下に保存されることを確認する
• 対象のサブエージェントの役割がタスクに合致することを確認する
• 書き込み可能な委任を行う前に、書き込み範囲が重複していないことを確認する

結果を受け入れる前：

• 外部 CLI ルーティングを使用した場合、ルーティングされた呼び出しが success: true で、終了コードが 0 であることを確認する
• サブエージェントが指定された上流成果物を読んだことを確認する
• サブエージェントがレビューバンドル、またはその全内容に相当するものを読んだことを確認する
• サブエージェントがアクション記録の各フィールドを埋めるのに十分な詳細を返したことを確認する
• Current Artifact が安定したレビュー対象成果物を指していることを確認する。大幅なドラフト編集が行われた場合は、記録を更新する
• 出力に差分の基準と変更ファイルが記載されていることを確認する
• 修正後もバンドルが現在の成果物のハッシュと一致していることを確認する
• 出力に具体的な所見、または所見なしという明示的な結論が含まれていることを確認する
• 該当する場合、出力に要件／計画との整合性に関するコメントが含まれていることを確認する
• 出力の末尾に明確な判定があることを確認する
• 受け入れる前に、主張されたファイルへの影響、成果物への影響、または所見を、実際のワークツリー差分、実際の成果物、および以前にロックされた再帰的ドキュメントと照合する
• フェーズ成果物に Reviewed Action Records、Main-Agent Verification Performed、Acceptance Decision、Refresh Handling、Repair Performed After Verification が記録されていることを確認する
• 実質的に寄与した作業について、主張されたファイルへの影響または成果物への影響が none のままになっているアクション記録は却下する
• コンテキストを欠く、曖昧で具体性がない、または必須チェックが抜けている出力は却下する

ルーティングされたサブエージェントが失敗、所見、未完了の作業、success: false、またはゼロ以外の外部 CLI 終了コードを報告した場合、その結果を受け入れてはいけません。コントローラーは監査・修正・再試行のサイクルを実行する必要があります。失敗した試行と診断証拠を記録し、修正する権限がある場合は、同じ限定された役割に修正内容を正確に伝え、ルートを再実行してから、実際の差分と成果物に対するコントローラーの検証を繰り返します。ルーティングされた役割で問題を修正できない場合、またはルートが引き続き利用できない場合は、ローカルで修正するか自己監査の証拠を使用する前に、明示的なフォールバックを記録してください。

推奨される役割

アナリスト

AS-IS 分析、根本原因分析、その他、独立した分析レビューが必要な監査対象フェーズでは、次の項目を確認するために使用します。

• 現在のドラフト
• 上流のロック済み成果物
• 記録済みのベースラインとの差分
• 要件の網羅状況
• ギャップ、乖離、修正の必要性

プランナー

フェーズ 2 の計画、および後続の成果物で対象範囲内のすべての R# を明示的に網羅し、曖昧な要約で隠さないことが求められる、トレーサビリティを重視したチェックに使用します。

コードレビュアー

フェーズ 3.5、またはリスクの高いフェーズ 3／4 の監査に使用します。

確認事項：

• 要件と実装の整合性
• 計画と実装の整合性
• 主張されたスコープと git diff の整合性
• コード品質と保守性
• テストの妥当性と TDD への準拠

メモリー監査担当

フェーズ 8 で、変更されたパス、メモリーステータスの遷移、ルーターの更新が、最終的に検証されたリポジトリの状態と一致していることを確認するために使用します。

テスター

フェーズ 4 で、テストの妥当性、正確なコマンド、エビデンスの取得、テスト結果を信頼する前に実装が本当に完了しているかを監査するために使用します。

実装者

フェーズ 2 で、具体的なファイル所有権が定められた真に独立したサブフェーズがある場合にのみ使用します。

コントローラーは所有権を明示的に割り当てる必要があり、これをデフォルトで広範な「並列モード」として提示してはいけません。

引き継ぎテンプレート

監査やレビューを委任する場合は、常に次の構成を使用してください。recursive-review-bundle でバンドルを生成し、そのパスとフェーズ固有の指示を渡す方法を推奨します。

Review Bundle Path: `/.recursive/run/<run-id>/evidence/review-bundles/<bundle>.md`
Phase: `03.5 Code Review`
Artifact path: `/.recursive/run/<run-id>/03.5-code-review.md`
Role: `analyst`
Audit execution expectation: return findings plus `Audit: PASS` or `Audit: FAIL`

Bundle freshness check:
- confirm changed files, evidence refs, and audit questions still match the latest repaired draft
- confirm relevant addenda are included; do not hand-wave plan or requirement amendments that live in addenda

Additional audit questions:
- Which `R#` are still incomplete?
- Which changed files drift from the plan?
- Is required evidence missing?
- Is repair required before lock?

Action-record expectation:
- return enough structured detail for `recursive-subagent-action`
- prefer the stable reviewed artifact for `Current Artifact` when recording review/audit work
- cite upstream artifacts reread, relevant addenda, prior recursive evidence, changed files or code refs reviewed, claimed findings, and verification handoff items

セルフ監査へのフォールバックパターン

サブエージェントを利用できない場合は、フェーズ成果物で同じチェックリストを再利用し、次を記録します。

## Audit Context

Audit Execution Mode: self-audit
Subagent Availability: unavailable
Audit Inputs Provided:
- `/.recursive/run/<run-id>/...`

その後、次の監査サイクルをローカルで最後まで実施します。

1. フェーズ成果物を作成または改訂する
2. 上流の成果物を読み直す
3. 記録済みの差分の基準および変更されたファイルと照合する
4. ギャップを記録する
5. 作業を修正する
6. 監査を再実行する
7. フェーズが実際にロック可能な状態になった場合にのみ、Audit: PASS に設定する

出力の却下ルール

委任された結果が次のいずれかに該当する場合は、却下してください。

• 成果物のパスまたはフェーズ名を記載していない
• レビューバンドルのパスを記載していない、または同じバンドル内容を明確に再提示していない
• 読み直した上流の成果物に触れていない
• 有効な入力セットに含まれていた関連する追補を無視している
• バンドルに含まれていた関連する過去の再帰的エビデンスまたはメモリー参照を無視している
• 差分の基準または変更されたファイルをレビューしていない
• レビューの説明で、変更されたファイルまたはコード参照を示していない
• 委任した作業の成功を主張しているが、コントローラーが実際のファイル、実際の成果物、実際の差分所有範囲に照らしてその主張を検証していない
• 推測なしでは、永続的なサブエージェントのアクション記録に変換できない
• 必要な場合に、要件または計画との整合性を扱っていない
• 根拠のある所見がなく、一般的な称賛しか示していない
• 明確な判定がない

参照

• 正式なワークフロー：/.recursive/RECURSIVE.md
• 成果物テンプレート：../recursive-mode/references/artifact-template.md
• コードレビュアーのプロンプト：agents/code-reviewer.md
• 実装者のプロンプト：agents/implementer.md