mcpField
R
run-parallel-agents-feature-build

run-parallel-agents-feature-build

github.com/ulpi-ioエージェントワークフロー5145 回インストール9 週間前に更新
リポジトリ

run-parallel-agents-feature-build について

独立したソフトウェア構築タスクで、Claude Code の並列 Agent 実行を調整するスキルです。タスクの独立性確認、各 Agent への詳細な指示、コード作業の worktree 分離、結果のレビューを重視します。

主な機能

  1. 01タスクの独立性と範囲の確認
  2. 02詳細な Agent 指示の作成
  3. 03並列 Agent 呼び出しの一括起動
  4. 04コーディング作業の worktree 分離
  5. 05結果の追跡と競合の確認
  6. 06状況と阻害要因の報告

活用シーン

  1. 01独立した機能タスクの並列実行
  2. 02計画済み構築タスクの同時実行
  3. 03分離されたコード変更の調整
  4. 04Agent の結果と阻害要因の集約

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ulpi-io/skills --skill run-parallel-agents-feature-build

インストール後、Claude Code で/run-parallel-agents-feature-buildを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
agent_matching_logic.md
agent-runtime-semantics.md
task-exit-gate.md

詳細

このスキルは、実際のエージェントツール実行を調整します。次のルールは必ず守ってください。 1. 何かを開始する前に、独立性を確認してください。 2. 新規の `subagent_type` エージェントにはタスクのコンテキストが引き継がれないため、起動するエージェントごとに完全なプロンプトを作成してください。 3. 複数の `Agent(...)` ツール呼び出しを含む、1つのアシスタントメッセージで、並列エージェントをすべて起動してください。 4. 独立したレーンには `run_in_background: true` を使用し、バックグラウンド出力をポーリングしたり、末尾を確認したりしないでください。 5. コードを書くレーンでは、タスクが明示的に読み取り専用でない限り、`isolation: "worktree"` を使用してください。

並列エージェントによる機能構築

入力

  • $request:任意の計画パス、タスクの選択、または execute layer 0 from .ulpi/plans/foo.json や build these three features in parallel のようなユーザーの指示。

目標

Claude Code の実際の並列エージェントランタイムを活用し、ファイルの競合、コンテキストの欠落、見せかけのオーケストレーションを避けながら、独立した構築タスクを同時に実行します。

ステップ 0:作業候補を特定する

作業の信頼できる情報源を特定します。

  • 承認済みの DAG 計画
  • 明示されたユーザーのタスクリスト
  • 明確に分割された、独立した実装レーンの集合

次に、以下を判断します。

  • タスク数
  • 依存関係
  • 書き込み範囲の重複
  • 各レーンが調査やデバッグではなく、構築作業かどうか

次の場合は、このスキルを使用しないでください。

  • 独立したレーンが 3 つ未満の場合
  • いずれかのレーンが、別のレーンの結果に依存する場合
  • 複数のレーンが同じファイル、または同じ限定的なサブシステム領域に書き込む場合
  • タスクがまだ計画または調査の段階にある場合

分解が曖昧で、安全な並列化がユーザーの選択に左右される場合に限り、AskUserQuestion を使用してください。

成功基準:並列実行しても安全な、具体的な構築レーンが定まっていること。

ステップ 1:独立性を仮定せず、確認する

候補となる各レーンについて、以下を確認します。

  • 必要な入力がすでに揃っている
  • 他のレーンの出力を先に得る必要がない
  • 書き込み範囲が互いに重複していない
  • 各レーンで検証を実行するか、曖昧さなくマージ後に検証できる

計画がある場合は、その依存関係グラフと書き込み範囲を主要な情報源として扱います。

計画がない場合は、同等の一時的な構成を導き出します。

  • レーン名
  • 範囲
  • 対象となるファイル
  • 受け入れ基準
  • 検証コマンド

並列実行の成否を左右するランタイムのルールについては、references/agent-runtime-semantics.md を読み込んでください。

成功基準:すべてのレーンを、マージ時の競合リスクなく独立して実行できること。

ステップ 2:各レーンに適切なエージェントを割り当てる

以下の点に基づき、各レーンに最も適した専門エージェントを選択します。

  • リポジトリの技術構成
  • 対象のファイルとディレクトリ
  • フレームワーク固有のパターン
  • 実装作業か、一般的なサポート作業か

詳しい選定ルールと例外については、references/agent_matching_logic.md を読み込んでください。

実用上の基本方針:

  • 利用可能な中で、最も専門性の高いフレームワーク/ドメインエージェントを使用する
  • より適したエージェントがない場合に限り、general-purpose を使用する
  • エージェントタイプを創作しない

成功基準:すべてのレーンに、根拠のあるエージェントが割り当てられていること。

ステップ 3:エージェントへの指示を完全な形で作成する

新規の subagent_type エージェントにはメインスレッドのタスクコンテキストが引き継がれないため、各プロンプトには以下を含める必要があります。

  • 正確な作業範囲
  • このタスクの目的
  • 確認対象のファイルまたはディレクトリ
  • 書き込み範囲
  • 従うべき制約とパターン
  • 受け入れ基準
  • 検証コマンド
  • レーンでコードを書くのか、調査のみを行うのかを明示する指示

DAG 計画に基づく作業では、以下を維持してください。

  • タスク ID
  • 受け入れ基準
  • 書き込み範囲
  • 検証コマンド
  • レビュー要件

タスクが ID、ルーティング、レジストリ、または分離に関わる場合は、完了を宣言する前に、レーンで references/task-exit-gate.md を使用するよう指示してください。

成功基準:各レーンへのプロンプトが完全であり、新規エージェントが基本的な確認を求めずに作業を開始できること。

ステップ 4:すべてのエージェントを並列で一括起動する

複数の Agent(...) ツール呼び出しを含む、単一のアシスタントメッセージで、すべてのレーンを起動します。

コードを書くレーンの起動に必要な設定:

  • subagent_type:一致するエージェントタイプ
  • description:3~5語の短い説明
  • prompt:タスクの詳細な説明
  • run_in_background: true
  • isolation: "worktree"

ランタイム固有のルール:

  • ユーザーが並列作業を依頼した場合、複数のアシスタントメッセージに分けてエージェントを起動しないでください
  • コードを書く作業で安全性が重要な場合、非同期実行や分離の設定をエージェントのデフォルトに任せないでください
  • ここでは読み取り専用のフォークを使わないでください。このスキルは、新しい専門ビルドエージェント向けです

これらのルールの根拠となる正確な情報は、references/agent-runtime-semantics.md を読み込んでください。

成功基準:独立したすべてのレーンを、明示的で安全なランタイム設定を指定して同時に起動します。

ステップ 5:ポーリングせずに完了状況を集約する

起動後:

  • 重複しない調整作業を続けます
  • バックグラウンドのトランスクリプトをポーリングするのではなく、完了通知を待ちます
  • 詳細を確認する具体的な理由がない限り、返されたエージェントの要約を信頼します

各レーンの完了時に、次の情報を記録します。

  • ステータス
  • 変更したファイル
  • 検証結果
  • ブロッカー、または説明からの逸脱

レーンがブロックされている場合、成功としてまとめた報告の中に隠さないでください。

成功基準:不要なトランスクリプトでのやり取りを増やさず、起動したすべてのレーンの結果を追跡します。

ステップ 6:レビュー、競合の確認、完了処理

レーンをマージ済みとして扱う前に:

  • 完了したレーン間で、書き込み範囲に競合がないか確認します
  • 計画に review フィールドが指定されている場合は、対応するレビュースキルを呼び出します。
    • codex → codex-review
    • claude → claude-review
    • kiro → kiro-review
  • レーンが構造化タスク計画に基づく場合は、そのレーンが references/task-exit-gate.md の要件を満たしていることを確認します

競合がある場合:

  • 自動集約を停止します
  • 重複しているファイルを特定します
  • 意図的にマージするか、ユーザーに判断を仰ぎます

成功基準:完了したレーンは、完了扱いにする前にレビューされ、競合がないことを確認します。

ステップ 7:集約した結果を報告する

次の内容を要約します。

  • 実行したレーン
  • 各レーンを担当したエージェント
  • レーンごとの完了状況
  • 変更したファイルや領域
  • 実施したレビュー
  • 残っているブロッカーや後続作業の順序

一部のみ成功した場合は、明確に伝えてください。並列実行が有益なのは、どのレーンが実際に完了したかをユーザーが把握できる場合に限られます。

成功基準:ユーザーに、簡潔で正確な並列実行の概要を伝えます。

ガードレール

  • 真に独立したレーンが 3 つ未満の場合、このスキルを使わないでください
  • 書き込み範囲が重複するタスクや、依存関係のあるタスクを並列化しないでください
  • 大規模なエージェント一覧や起動テンプレートを SKILL.md に直接記載しないでください
  • 新しいエージェントが周辺タスクのコンテキストを把握していると想定しないでください
  • ユーザーから明示的に依頼されない限り、バックグラウンドのエージェント出力をポーリングしたり、末尾を読み続けたりしないでください
  • 明示的な起動パラメーターの指定がより安全な場合、エージェントの background や isolation のデフォルト設定に頼らないでください
  • disable-model-invocation を追加しないでください。ユーザーが並列実行を依頼したときに、このスキルを引き続き利用できる状態にしてください
  • context: fork を追加しないでください。このワークフローは、新しい専門エージェントを調整するためのものであり、読み取り専用のスキルフォーク向けではありません
  • paths: を追加しないでください。このスキルは汎用のオーケストレーションスキルです

参照資料を読み込むタイミング

  • references/agent-runtime-semantics.md エージェントのランタイムルールについて、根拠となる情報を確認する場合に使用します。新しいコンテキスト、単一メッセージでの並列起動、バックグラウンド動作、worktree による分離、明示的なパラメーターの優先順位を扱います。

  • references/agent_matching_logic.md エージェント選定の詳細ルールや、フレームワーク固有の例外を確認する場合に使用します。

  • references/task-exit-gate.md 受け入れ基準、書き込み範囲、検証要件を含む構造化計画に基づいたタスクの場合に使用します。

出力仕様

以下を報告してください:

  1. 解決済みの並列レーンセット
  2. 各レーンへのエージェントの割り当て
  3. 起動状況
  4. 各レーンの完了状況とレビュー状況
  5. 競合、ブロッカー、または残っている逐次作業

コメント