build-in-waves

エフェメラルパス：FEATURE_CODE / <CODE> を解決してから templates/skills-ephemera-paths.md に従います（機能ルートは .skills/<CODE>/）。パックのシードは次の順に解決し、最初に存在するパスを使用します：（1）この SKILL.md と同じ場所にある templates/、（2）変数が設定されている場合は ${CLAUDE_PLUGIN_ROOT}/templates、（3）この SKILL.md を基準にした ../../../templates。

ウェーブ単位でビルドする

承認済みの継続的な計画を、依存関係を考慮する単一のスケジューラーで完了まで進めます。準備完了タスクが1件なら逐次実行します。準備完了タスクが複数あり、互いに独立していて作業対象が重複しない場合は、並列ワークツリーで実行できます。同じ依存関係レーン内の関連タスクでは、上限付きのワーカーおよびレビュアーのリースを再利用できます。各タスクには、それぞれのコミット、レポート、エビデンス、2つの判定が必ずあります。タスク間に人間による一時停止はありません。

**コンテキストのルール：**意味単位の境界、またはハードリースのトリガー後は、新しいコンテキストを使用するのが標準です。有効なレーンリース内では、ロールのコンテキストを再開し、タスクの差分だけを渡します。大容量の成果物は貼り付けたテキストではなく、.skills/ 配下のファイルパスで渡します。

**進行状況の説明：**ツール呼び出しの間に出す短い説明は最大1行です。記録は台帳とツールの結果に残します。

**共有コントローラーの手順：**必須サブスキル：execute-common を使用します。セットアップの事前チェック／台帳／ToDo の開始時、または最後のタスクの開始時に ../execute-common/SKILL.md を読み込みます。これらの手順とクローズシーケンスの述語は、すべてこのファイルに集約されています。 このファイルは継続モードのスケジューリングとバリアを担当します。共有タスクのライフサイクルは ../execute-common/task-lifecycle.md にあり、読み込みは1回だけです。

モードの所有権

このスキルを呼び出すと、継続的な実行が選択されます。tasks.md をそのルートに合わせて、続行します。

tasks.md の Execution-mode:	アクション
continuous	続行
story-unit	必須サブスキル：build-by-story を使用
欠落／unset／無効	tasks.md に Execution-mode: continuous を書き込みます（追跡対象の場合はコミットします）。続行

ユニットのバリア、ユニットの導出、人間によるユニット単位の停止は、build-by-story だけが担当します。

考え方	実態
「ヘッダーには story-unit とあるが、このままここに留まってウェーブを実行しよう」	build-by-story に引き継ぎます
「サイズの目安としてユニットを導出してから、継続モードで進めよう」	ウェーブは Depends-on だけを基準にします
「リードが人間による停止を求めているので、継続モードの途中で一時停止しよう」	人間の承認を必要とする停止は build-by-story が担当します
「タスクは小さく、仕様も完全なので、自分で書こう」	サイズによってルートが変わることはありません。コントローラーがコードを書く場合は build-inline です。ここでは、すべてのタスクに個別の実装担当者を割り当て、それぞれを個別にレビューします。ベースラインでは、4回中2回、コントローラーが4つすべてのタスクを実装してからレビュアーを割り当てており、1人のレビュアーが4つすべてをまとめてレビューしていました

セットアップ

1. モードの所有権。 上記の表を適用します。完了条件：ヘッダーが continuous で、このスキルを継続するか、build-by-story に引き継いでいること。
2. セッションの事前確認。 ../execute-common/SKILL.md の Session preflight を適用します。 完了条件：該当セクションの完了条件を満たしていること。
3. 台帳の確認。 ../execute-common/SKILL.md の Ledger check を適用します。 完了条件：次のタスクがわかっていること。
4. 計画を読む。 tasks.md を最初から最後まで一度読みます。ディスパッチ用に、Global Constraints のパスと内容ハッシュを記録します。ブリーフでは、レビュー担当者向けの各プロンプトに毎回貼り付けるのではなく、正規のセクションを参照します。 docs/agents/project.md がない場合は、その旨を伝え、configure-repo を提案し、Global Constraints から検証コマンドを取得します。 ## Team に名簿／バンドがある場合は、バンド packaging のみを読み込みます。Solo の二重判定レビューは決して省略しないでください。完了条件：制約を一語一句そのまま把握していること。
5. To-do — GATE。 ../execute-common/SKILL.md の Todos — GATE を適用します。 完了条件：リストが計画を反映し、Close 分岐の To-do も含まれていること。
6. 実行前の計画レビュー。 内部的な欠陥（矛盾、アサーションのないテスト、計画で必須とされているコピー＆ペーストのロジック）がないか、一度確認します。見つかった問題はすべて一つの質問にまとめて、ディスパッチ前にユーザーへ尋ねます。問題がなければコメントしません。 完了条件：競合が解消されているか、競合がないこと。
7. 実行可能セットの計画。 すべてのタスクの Depends-on: と Files: ブロックを読みます。名前が指定されたタスクは先に完了させます。Depends-on: none は前提条件がないことを意味し、行がない場合はそれ以前のすべてのタスクが前提条件となります。依存関係グラフから次の実行可能セットを算出します。サーフェスが重複せず、ランタイムが安全なワークツリー分離に対応している場合に限り、実行可能セットを並列化できます。Max-concurrency の上限が承認済みで指定されている場合は適用します。指定がなければ auto とします。 完了条件：すべてのタスクについて、依存関係上の位置、サーフェスの重複結果、適用するレーン／並行数の判断が明確になっていること。

継続スケジューラー

一つのタスクループについては ../execute-common/task-lifecycle.md を読み込みます。スケジューラーは、タスク ID、レーン、現在のベースリビジョン、ブリーフのパス、レポートのパス、レビューパッケージのパス、アクティブなリース ID を提供します。ディスパッチ、ステータス、レビュー、修正、エビデンス、台帳のルールはライフサイクルが管理します。

ワーカーまたはレビュー担当者を再開する前に、../execute-common/SKILL.md のリース事前確認を実行します。

1. 意味上の境界： 区切られた単位の終わり、または次のタスクによってそのロールに必要なコンテキストが大きく変わる時点で交代します。
2. コンテキストの安全性： システム指示、ツール、保持された履歴、カプセル、タスク差分、出力用の余裕を見積もり、アクティブなコンテキスト上限と照らし合わせます。
3. 価格の安全性： 日付付きのプロバイダー／モデルの pricing_policy を適用します。リクエストの予測コストが全トークンの急増点を超える場合、または続行するコストが新しいロールコンテキストを開始するより大幅に高い場合は、ディスパッチ前に交代します。
4. 強制交代： コンパクション後、広範囲に及ぶスコープ／不変条件の変更後、ハーネスの変更後、またはコンテキスト混乱の兆候が最初に現れた時点で交代します。理由を記録し、カプセルと台帳を通じて継続性を保ちます。

Ready セット、レーン、バリア

1. Depends-on: から次の Ready セットを計算します。タスクは、すべての前提条件が台帳にクリーンとして記録された後にのみ Ready になります。
2. セットにタスクが 1 つだけなら、フィーチャーブランチで共通のタスクライフサイクルを実行します。
3. セットに複数のタスクがある場合は、各ペアの Files: の対象範囲が重複していないことを証明し、worktree_isolation を確認します。重複がある場合、または分離が欠けている場合は、実効セットを直列に変更し、その低下をランタイムサイドカーに記録します。
4. 並列セットでは WBASE を記録します。各レーンでは実行全体を通じて 1 つの worktree を維持し、ビルドキャッシュを温存します。タスクごとに新しい worktree を作ると、キャッシュがない状態から再ビルドすることになります。初回は次を実行します。 git worktree add .worktrees/<branch>-lane<k> -b <branch>-taskN WBASE 以降のセットでは、次を実行します。 git -C .worktrees/<branch>-lane<k> switch -c <branch>-taskN WBASE 共通のライフサイクルを呼び出します。ワーカーまたはレビュー担当者のリースが Ready セットをまたいで継続できるのは、自身の依存関係レーンに沿う場合のみです。
5. セット内のすべてのタスクで Standards と Spec の判定がクリーンになったら、タスク順に決定論的にマージします。競合が発生したらスケジューラーを停止します。決して根拠なく解決してはいけません。続いて、マージ後の HEAD でウェーブゲートを実行します。ワークスペース内のすべてのターゲットをコンパイルし、Lint を実行します（project.md の Wave gate があればそれを使用し、なければその型チェックと Lint のコマンドを使用します）。Lint のベースラインに照らして判定します。失敗した場合は台帳に行を記録しません。必須サブスキル：root-cause を使用し、修正のディスパッチを 1 回行ってから、ゲートを再実行します。成功した場合はタスクごとに台帳へ 1 行記録します。最後の Ready セットの後にレーンの worktree を削除します。
6. Ready セットを再計算します。連続モードではタスク間の許可待ちはありません。また、レビューのバリアが開いている間は、タスクを先へ進めてはいけません。

実装担当者のステータス処理

ステータス	対応
DONE	差分をまとめて、タスクレビューに回します。
DONE_WITH_CONCERNS	懸念事項と .skills/<CODE>/implementation-notes.md の両方を読みます。記載内容は implementer-prompt.md の Deviations の 9 フィールドの手順に一致している必要があります。メモのパスがない、不完全なフィールドがある、または逸脱を申告しながら 5 フィールドしかない場合は不完全です。まずログに記録するよう再ディスパッチします。影響をマッピングして、reroute-plan / realign-spec に該当する場合、または計画の妥当性が損なわれる場合は、必須サブスキル：reroute-plan を使用します（クリーンな DONE として受け入れてはいけません）。
NEEDS_CONTEXT	指定された情報を提供し、同じモデルに再ディスパッチします。
BLOCKED	コンテキスト不足なら提供します。上限なら、より強力なモデルに切り替えます。大きすぎるなら分割します。計画が誤っているなら、必須サブスキル：reroute-plan を使用します。

再ディスパッチはタスクごとに 2 回までです。それでも DONE にならない場合は、ユーザーにエスカレーションします。何も変更せずに同じモデルへ再試行を強制してはいけません。

オペレーターからのメッセージによって計画が変わる場合（制約の追加、スコープの縮小、要件の削除など）は、仕様やコードを編集する前に必須サブスキル：reroute-plan を使用します。

モデルのティア分け

すべてのディスパッチで、モデルを明示的に指定します。指定を省略すると、セッションのモデル（通常は最も高価なモデル）が引き継がれます。

• 低コスト： 文字起こし／単一ファイルの機械的な修正。
• 中位の下限： すべてのレビュー担当者、および文章の指示に基づいて作業するすべての実装担当者。
• 最上位： 設計上の判断、広範なコードベースの理解、ブランチ全体のレビュー。

差分の規模とリスクに応じて、レビュー担当者のティアを調整します。

レビュープロンプトの衛生管理

• 計画で求められた欠陥も指摘事項です。どちらが優先されるのかを確認します。
• タスク固有の具体的な理由なしに、「すべてを確認する」といった範囲の広い依頼をしてはいけません。
• 実装担当者がレポートですでに実施したことを証明しているテストを再実行してはいけません。

永続的な進捗

Todo は現在のセッションの状況を示し、台帳は圧縮後も残ります。圧縮後は、会話の記憶よりも台帳と git log を信頼します。

• ウェーブの途中でクラッシュした場合は、未マージのタスクブランチを破棄し、レーンの worktree を WBASE に戻して、WBASE からウェーブ全体を再実行します。.skills/（Git の追跡対象外）が消去されている場合は、git log から再構築します。

最後のタスクの後

../execute-common/SKILL.md の Close sequence をすべて適用します。ここで手順を言い直したり、一部だけを抜き出したりしてはいけません。

完了条件：そのセクションの Done when を満たしていること。

インラインルート

実装担当のサブエージェントを使わずにコントローラー側で順次実行する場合は、build-inline が担当します。ユーザーがインラインを選択した場合、または環境で実装担当に処理を振り分けられない場合は、必須サブスキルとして build-inline を使用してください。ディスパッチせずに、このスキルのサブエージェントループを中途半端に実行しないでください。

危険信号 — 禁止事項

• Execution-mode が story-unit の場合にこのループを実行する（build-by-story に引き継いでください）
• ユーザーがインライン／サブエージェントなしを選択した場合にこのスキルを使い続ける（build-inline に引き継いでください）
• continuous の実行中にユニットのバリア、ユニットの導出、または人間によるユニット停止を実行する
• タスクの合間に、続行してよいか尋ねるために一時停止する
• 同じワークツリーで2人の実装担当を実行する、または分離された isolate-workspace と、互いに競合しない作業範囲の確認なしに並行実行する
• 並行ウェーブ内のすべてのタスクがレビューに合格する前にウェーブをマージする、またはウェーブゲートがグリーンになる前に台帳に記録する
• サブエージェントに計画ファイル全体を渡す。ブリーフがその作業の全情報である必要があります
• 修正後の再レビューを省略する、または両方の判定が揃っていないレビューを受け入れる
• Critical／Important の指摘が未解決のまま次のタスクに進む
• 実装担当をディスパッチせず、コントローラー側でタスクのコードを書く
• 1回のレビューディスパッチで複数のタスクをレビューする
• 実装担当による自己レビューをタスクレビューの代わりにする
• レビュアーに指摘しない内容を伝える、またはディスパッチ時に重大度を事前評価する
• 差分パッケージなしでレビュアーをディスパッチする
• 台帳で完了と記録されているタスクを再ディスパッチする