implement-with-subagents

サブエージェントで実装する

権限、順序、検証、復旧、受け入れの決定権を保持しながら、承認済みのバックログ作業を調整します。作業項目ごとに新しいサブエージェントを割り当てますが、唯一の受け入れブランチで同時に変更できるエージェントは1つだけにします。

$to-product では、自律的な契約により、担当者の承認とブロッカーポリシーが定められます。その契約と実行記録のパスがあれば、それをすべての依頼に含めてください。

条件を満たす読み取り専用の質問、または副作用のないチェックに限り、$parallel-execution を使用してください。実装ワーカーを同時に実行してはいけません。

入力

明示的に許可されたスコープを1つ必須とします。対象は、承認済みの子項目すべてとEpicのクローズを許可するアクティブな EPIC-NNN／パス、または空でない WORK-NNN ID／パスの集合です。会話ですでに曖昧さのないスコープが確立されている場合は、それを使用できます。そうでなければ候補を列挙して確認してください。タイトルが似ていること、変更されたパス、ランクが隣接していることから集合を推測してはいけません。集合によって、兄弟項目、親項目、スコープ外の依存関係、Epicのクローズが許可されることはありません。Epicは調整のコンテキストを提供しますが、子項目の承認済み成果の範囲を広げることはありません。

任意の model と reasoning effort の設定により、実装の階層を選択できます。ユーザーが統一した設定を要求しない限り、読み取り専用の振り分けには $parallel-execution を使用してください。インターフェースで設定を適用できない場合は、その旨を一度だけ報告し、デフォルト設定を使用してください。

事前確認

バックログのワーカーを起動したり、バックログを変更したりする前に、次のことを行います。

1. リポジトリの指示を確認し、Epicの受け入れ単位と証拠の一括メンテナンスルールを含む、現在のsetup-projectの足場が整っていることを必須とします。旧式のプロジェクトは、委任する前に $setup-project に案内してください。
2. node scripts/validate-project.mjs を実行します。ベースラインが無効な場合は停止してください。
3. 許可されたレコード、ランク、関係性、クレーム、インデックス、Wiki参照と最寄りのインデックス、メンテナンス、調査、該当するガイダンス、影響を受けるコード、テストをすべて一度読み、単一の権限パケットにまとめます。読み取り専用の支援を割り当てるのは、ここで簡単には解決できない具体的な未解決の質問がある場合に限ります。一般的なコード、テスト、ガイダンス、リスクの棚卸しを依頼してはいけません。
4. ブランチ、リモート、変更、最近の履歴を確認します。$create-conventional-branch の不変条件を適用してください。無関係な作業は保持します。プライマリコミットを不変のEpic固定点として記録してください。
5. 提案段階または形式不備の作業、ランクや準備状況の欠如、一貫性のない、または対象外のクレーム、スコープ外のブロッカーを拒否します。$to-product の外では、追加、ランク変更、キャンセル、親の変更、スコープ変更を行ってはいけません。$to-product の下では、PRDで要求されるワークフロー状態を $backlog で修復し、再検証してから続行してください。

Epicの場合、暫定的な順序、依存関係、共有インターフェース、競合領域を実稼働コードと照合してください。子項目ごとに再検証します。

実行トポロジー

Epic

1. $create-conventional-branch を一度呼び出し、その後、Epicと必須の子項目について $implement の開始／クレーム処理を1回実行します。
2. 次に実行可能な子項目を、新しいサブエージェント1つに割り当てます。内部の暫定子項目パケットには、現在のブランチとHEADを明記します。マネージャーは並行して変更を行いません。ワーカーは実装とコミットを直接行い、対象を絞ったチェックとスモークテストによる証明を実施し、レビューやガバナンスの変更は行わずに証拠を返します。
3. コミットと証拠を検証し、実行可能な状態を再確認してから、次の子項目を割り当てます。別の項目に同じワーカーを再利用したり、依存する子項目を早く開始したりしてはいけません。
4. すべての子項目が暫定状態になったら、Epicのクローズ手順として $implement に従います。レビュー1回、修正の直接確認、代表的なテストスイートと妥当性を根拠づけたマトリックス、照合1回、マージ1回、受け入れ状態の公開、最後にアトミックなトランザクションを1回実行します。

子項目にブランチ、プライマリへのマージ、終端状態を設定してはいけません。子項目ごとの証拠をコミットしたり、別のタスク文書を管理したりしてはいけません。

スタンドアロン WORK セット

項目を順番に処理します。それぞれについて、唯一の受け入れブランチを開いてトランザクションを開始し、新しいサブエージェントに、現在のブランチと HEAD を明記した内部用の暫定スタンドアロンパケットを渡します。マネージャーは並行して変更を行いません。返されたコミットと証拠を検証したら、ここで $implement WORK-NNN を再開し、レビュー、スイート、マージ、照合、最終トランザクション、ブランチ削除を行います。ワーカーを再利用してはいけません。

ワーカーを利用できない場合は、$to-product の外で停止します。その配下に利用できないワーカーを記録し、ここで最上位の $implement を直ちに実行します。キャパシティをブロッカーとして報告してはいけません。

検証と復旧

引用されたコミット、マージの祖先関係、主張、順位、ステータス、インデックス、アーカイブ、レビューモード、対象を絞ったチェック、スイートの鮮度、マトリックスの根拠、照合、受け入れを検証します。新しく一貫性のある証拠は信頼し、証拠が欠落している、古い、矛盾している場合、またはコードに影響する統合入力が異なる場合に限り、再実行します。

Epic では、受け入れブランチとマージがそれぞれ 1 つであること、原子的に完了するまですべての子項目が暫定であること、包括的なレビューが 1 回のみであること、子項目や修正レビューがないこと、代表スイートが 1 つであること、マトリックスの拡張に根拠があるかリリースマトリックスが完全であること、Wiki/ADR トランザクションが 1 つであること、通常の開始トランザクションと最終バックログトランザクションがそれぞれ 1 回のみであることを必須とします。

無効または不完全な結果は、同じワーカーを使って対象を絞った証拠を添えて再試行します。$to-product の配下では、ワークフローの失敗はここで修正するか、ローカルで実行します。3 回の試行が許されるのは技術的な失敗のみです。その後、$create-conventional-branch の保留プロトコルに従い、クレームを解放し、未完了の記録を ready に戻して、独立した結果の処理を続けます。Epic の部分的な状態を受け入れたり、ほかの実行者のクレームを変更したりしてはいけません。

Epic の完了

Epic の終了を許可するのは、明示的な Epic 入力のみです。$implement とその Epic リファレンスに従い、オーケストレーター固有のレビュー、スイート、マージ、照合、完了ゲートを追加してはいけません。完了報告とリポジトリの証拠には、共有された単一の受け入れトランザクションセットが示されている必要があります。

呼び出し例

Use $implement-with-subagents with EPIC-012.
Use $implement-with-subagents for WORK-014, WORK-019, and docs/backlog/standalone/WORK-023-fix-export.md.
Use $implement-with-subagents with EPIC-012 using model gpt-5.6-sol and reasoning effort high.

最終報告

子項目の順序、エージェントとフォールバック、適用したモデルと労力または未対応であること、受け入れブランチ、コミットと対象を絞った証拠、レビュー、受け入れマージ、照合/ADR、トランザクション、最終的なクレーム/順位/ステータス/アーカイブの状態、公開された経過時間/トークン使用量、ブロッカーを報告します。スキップした場合や該当なしの場合も、Representative suite: と Retries, conflicts, rework: の行を正確に含めてください。

最後は Next step: で締めくくります。ブロックされている場合は正確な再開コマンドを記載します。それ以外の場合は、次に順位が最も高いスコープを指定した $implement-with-subagents または $implement、あるいは次に未解決の結果を指定した $discuss を記載します。