implement-with-subagents

サブエージェントを使った実装

基本原則

タスクグラフ全体を見て、実装の担当を一度だけ決定します。並列作業のない単一項目またはグラフでは、リードが実装を担当します。グラフに並列作業がある場合は、順次処理する最初と最後の項目も含め、すべての項目をワーカーに割り当てます。どちらの場合も依存関係の確認と、独立した最終レビューを維持します。修正は実装担当者が行い、委任する際は上限を定めたワーカーチェックアウトプールを再利用します。

モードの選択

• 提供されたオーケストレーションを実行せずに評価する場合のみ、review を使います。このモードには外部依存がありません。
• 提供されたチケットまたは計画タスクを実行する場合のみ、implement を使います。このモードでは、別個の /implement スキルは呼び出されません。

レビュープロセス

1. 許可されたリポジトリおよびオーケストレーションの状態のみを確認します。エージェントの起動、編集、コミット、ブランチの変更、ワークツリーのライフサイクル操作、リモートサービスへの接続は行わないでください。
2. タスクグラフ全体と、記録された事前チェックの選択を評価します。単一項目または並列作業のないグラフで、ワーカーを強制している場合は指摘してください。これらの実行ではリードが実装を行い、自己レビューを実施し、個別のタスク受け入れは不要です。並列作業があるグラフでは、順次処理する最初と最後の項目も含め、すべての項目をワーカーに割り当てます。委任する場合は、タスク単位のコミット、担当者による自己レビュー、対象を絞った検証、統合前のコントローラーによる受け入れを評価します。担当者の報告だけではタスクの受け入れを満たしません。別々のワークツリーを使っていても、共有ファイルの編集や未統合コードに依存する作業は独立しません。提示された準備状況、独立性、キャパシティを信頼できる情報として扱います。委任する実行では、準備が整った全項目を同時に割り当てます。状態から不足していると示されていない前提条件（テストの接続点、tdd、レビュアーの対応能力など）は、割り当てを保留する理由ではなく、実行時に確認する事項です。既存のチェックアウトを優先して割り当て、作業中の書き込み担当者には別々のスロットを割り当て、読み取り専用の補助担当者には既存のチェックアウトへのアクセスを割り当てます。
3. 各前提タスクのコミットが競合なく統合され、委任する場合は先に受け入れられ、影響を受けるチェックが統合後の同じ状態で再実行されて合格してから、依存タスクを解放します。タスクブランチでチェックに合格していても不十分です。通常のマージ後に、リードによる裁量的な受け入れを再度要求しないでください。ファイル間の相互作用、共有インターフェースの変更、またはマージ解決によって意味が変わる可能性がある場合は、統合後の差分を確認します。統合後の状態で入力と環境に変更がないと確認できた場合に限り、合格済みチェックを再利用します。受け入れ済みの項目は完了しているため、再割り当てしません。
4. 次のアクション、根拠、受け入れに関する不足点を報告します。実装を開始する前に停止してください。リリース可能性、安全な破棄、チェックアウトの処置を確認しますが、それらは変更しません。依存関係グラフが無効な場合、または安全でない重複がある場合は、割り当てを保留して具体的な不備を計画担当者に返します。順序を独自に作ったり、タスクや依存関係を削除したりしないでください。別の障害によって割り当てが妨げられている場合も、統合後の状態で再実行が必要なチェックをすべて挙げてください。

実装モード

前提条件

実装前に、動作を変える項目と、ユーザーが承認したテストの境界を特定してください。 各項目の担当者は、別途インストールしたtddスキルを直接使用します。動作を変える項目に承認済みの境界がない場合は、その項目を実装する前に合意を得てください。tddを利用できない場合は、動作に関する作業を始める前に停止してください。ドキュメントなど、意味のあるテストの境界がない項目には、対象を絞った検証を使用します。依存関係を暗黙にインストールしてはいけません。

どちらの経路でも、実装前に独立した読み取り専用のレビュー能力を確立してください。レビュー能力の確認のみを目的とするレビュアーを起動してはいけません。最終レビューには、書き込みを行わず、実装時の会話を引き継がない新しいエージェントを使用し、承認済みのソース、計画、リポジトリの規約、固定されたベース、および正確な候補ヘッドを含む自己完結した概要を渡してください。動作レビューと修復に記載のカバレッジ報告とともに、要件と規約の両方に照らした証拠付きの指摘と、ship、fix-first、またはrethinkの判定を求めてください。関連する境界の修復とブラウザーの失敗診断については、実装中もこのリファレンスを適用してください。PRのフィードバックはこのワークフローの対象外です。外部のレビュースキルやトラッカーのセットアップは不要です。独立したレビューを実行できない場合は、不足している能力を報告してください。最終レビューを省略してはいけません。別個のリスクや、個別の担当を割り当てるに値する大規模な作業がある場合に限り、レビュアーを追加してください。

実装前に、実装モードの手順を最後まで読んでください。この手順では、事前確認、割り当て、担当者向けの指示、タスクの受け入れ、統合、修復、最終検証を定めています。依存関係、タスク単位のコミット、または能力ゲートを満たせない場合は停止してください。委任された実行では、リードとして実装に切り替えず、ワーカーの空きを待ってください。

完了ゲート

reviewでは、変更を加えない評価、証拠、および受け入れ上の不足がある場合はその内容のみをもって完了としてください。implementでは、キューに入ったすべての項目にタスク単位のコミットがあり、各コミットがセルフレビュー済みであること（委任した場合は統合前に受け入れ済みであること）、最終的に統合されたヘッドですべての影響を受けるチェックと必須の全テストスイートが通過していること、統合後のレビューが最新であること、統合チェックアウトがクリーンであることを満たした場合に限り、完了としてください。開始時のチェックアウトにある無関係なユーザー作業は保持してください。実行中に作成されたすべてのワーカーチェックアウトについて、確認済みの読み戻しをもって廃止したか、理由を示して保持したかを報告し、タスクブランチの参照を保持してください。廃止の失敗、またはクリーンアップ能力の不足がある場合は、コードの検証に合格していてもワークフローは未完了です。項目とコミットの対応、正確な統合ヘッド、最終検証とレビューの証拠、チェックアウトの処置、および阻害要因を報告してください。そうでなければ、最初に未完了となったゲートで停止してください。PRおよびトラッカーへの提出は、このスキルの対象外です。