parallel

ユーザーが依頼した場合にのみ、並行して作業してください。それ以外の場合は、このセッションでタスクを1つずつ実行してください。タスクの独立性が保証となります。並行実行は、それを手軽に実現する方法にすぎません。

1. モードを選びます。デフォルトは Partition です。ファイルや状態を共有しない独立したタスクごとに、サブエージェントを1つ割り当てます。Race は、race.md に記載されているとおり、1つのタスクを複数回すべて試行するモードです。Coverage は、coverage.md に記載されているとおり、完了チェックを設けて1つの作業を多くの部分に分割するモードです。互いに関連する失敗には、どのモードも適しません。まず、まとめて調査してください。
2. Race または Coverage を実行する場合は、まずコストを伝えます。サブエージェントの数と、全体を何回試行するかを明示してください。ユーザーの同意を得てから開始してください。
3. Partition では、各ワーカーに担当範囲、背景情報、制約、期待する返答を含む簡潔な依頼を渡します。担当範囲は、1つのファイル、1つのサブシステム、または1つの問題に限定します。「すべてのテストを修正する」という依頼は、エージェントにとって範囲が広すぎます。エラーメッセージ、テスト名、関連パスなどの背景情報を依頼に含めてください。エージェントはセッションの情報を参照できません。制約には、「テストのみ」や「本番コードには触れない」など、変更してはいけないものを記載します。期待する返答には、統合作業をレビューできるよう、根本原因と変更内容の概要を含めます。
4. すべてのサブエージェントを同時に起動します。ファイルを編集するワーカーはそれぞれ別の Git ワークツリーで実行し、チェックアウトを共有させないでください。新しいワークツリーに含まれるのはコミット済みのファイルだけなので、クリーンなチェックアウトからワーカーを開始してください。
5. 結果が返ってきたら、変更を統合します。ワークツリーで作業したワーカーは、このチェックアウトではなく、パッチまたはブランチで変更を返します。各概要を確認してください。各パッチには git apply --3way を適用するか、各ブランチをマージします。競合が発生した場合は、変更の意図を踏まえて解決してください。バッチの完了を伝える前に、verify スキルを実行してください。その完全なゲートで、テストスイート全体を検証できます。

ルール：

• 次の3つの場合、Partition は適しません。失敗同士が関連していて、1つを修正すると他も直る可能性がある場合、問題の原因がまだ特定できていない場合、またはエージェントが同じファイルを編集する場合です。
• Race では、異なる設計を平均化することはありません。試行結果の形が異なる場合は、依頼の範囲が曖昧すぎたということです。依頼を書き直してください。完了チェックなしで Coverage を開始してはいけません。
• ワーカーのワークツリーとブランチは実行後も残り、ワーカーはそこから作業を続けられます。バッチが verify に合格したら、それらを削除するかユーザーに確認してください。ユーザーの同意を得てから削除してください。