milestone-rush

マイルストーンの迅速な完了

実際の現在の状態から、指定されたマイルストーンを完了します。調整された作業項目の成果物と、検証済みのマイルストーン境界でのリリースに責任を持ちます。

権限とゲート

• リポジトリとマイルストーンが正確に指定されていることを必須とします。明示的な呼び出しにより、対象範囲内の課題コメントと置き換え用の課題、ブランチとワークツリー、実装、検証、コミット、通常のプッシュ、プルリクエスト、レビュー対応、スカッシュマージ、設定済みの統合デリバリー、マイルストーンに設定されたリリース手順、ブランチのクリーンアップ、およびそのマイルストーンのクローズが許可されます。
• 確認済みの /roadmap-review からの引き継ぎ、または直接の呼び出しを受け付けます。直接呼び出しの場合は、実行前に現在の対象範囲、方針、準備状況、依存関係、成功の測定基準を確認します。マテリアルな再計画が必要な場合は、マイルストーンを黙って変更せずに停止します。たとえば、マテリアルな製品上の決定が却下または延期されたことを記録するクローズや、対象範囲の大幅な拡大が該当します。
• /deliver におけるミニ仕様として確認済みのロードマップ項目を扱うのは、その項目に成果、対象範囲と対象外事項、およびテスト可能な成功の測定基準が記載されている場合に限ります。
• プロジェクトの指示、着手可能および完了の定義、ブランチ保護、レビュー方針、リモートのデフォルトブランチを尊重します。無関係な作業を修正したり、ゲートを回避したり、上書きしたりしてはなりません。通常のブランチはマージのみとし、git-workflow だけが、ガード付きのネイティブスタック書き換え例外を適用できます。
• 計画またはワーカーの起動前に、references/orchestration.md に従ってリポジトリルートの ORCHESTRATION.md を読み、検証します。その後、references/event-ledger.md に従い、最初の課題、PR、またはワーカーの操作より前に、実行の最初のライフサイクルイベントを ingest コマンドに渡して、無視対象のイベント台帳を開始します。前提条件の段階で実行が停止する場合も同様です。ホストがシェルではなく台帳またはテレメトリ操作として取り込みを提供する場合は、それを使用します。どちらも利用できない場合に限り、台帳が利用できないことを報告します。

調整と計画

1. 最新のマイルストーン、issue、プルリクエスト、レビュー、チェック、デフォルトブランチ、ブランチ、worktree、および関連するローカルの作業ツリーの状態を取得します。現在のプロジェクト方針、完了条件、検証済みのオーケストレーションポリシー、または報告されているプロバイダー中立のフォールバックを確認します。
2. worktree を採用または作成する前に、オーケストレーションのリファレンスで定められたすべてのリポジトリ宣言済みレーン受け入れ前チェックを実行します。実装またはローカルゲート全体の実行前に、安全でない worktree を移動するか拒否します。既知の環境上の制限を確認するために、テストスイート全体を無駄に実行してはいけません。
3. 各マイルストーン項目と関連するローカル変更を、提供済み、オープンな PR、実装中、準備完了、ブロック中、または無効に分類します。再開するのではなく、有効な作業を再利用します。
4. クローズ済みの項目を、ソースとマージの証拠に照らして検証します。必要な作業が未完了のままクローズされている場合は、 references/scope-changes.md を確認します。
5. 現在のデリバリー範囲を調査し、オーケストレーションのリファレンスで求められているプロバイダー中立の CI 統合に関する推奨事項を含めます。これは計画上の成果物であり、ワークフロー、ラベル、ルールセット、コントローラー、認証情報、プロバイダー設定を変更する権限を与えるものではありません。実行に必要な機能が不足している場合は、 references/scope-changes.md にリポジトリが所有する前提条件として記録します。それ以外の場合は、安全な現行 CI のフォールバックとそのコストを記載します。
6. 依存関係と、競合が発生しそうな作業のグラフを作成します。ネイティブスタックは、真の依存関係チェーン、または独立してレビュー可能な各レイヤーを備えた、単一の大きな issue の論理的な分割として確認されたものを表す場合があります。最長の作業と早期のリスク低減を優先し、独立して準備が整った各ノードを、現在のプラットフォーム容量の範囲内で、分離されたサブエージェントと worktree に割り当てます。issue、ウェーブ、レビュー回数、再試行回数に個別の上限を設けてはいけません。
7. 各 issue または PR の移行後に、無視対象の .agent/HANDOFF.md で外側のワークフローの再開可能な状態を維持します。マイルストーンの識別情報、グラフ、アクティブな worktree、issue と PR の状態、ブロッカー、確認済みの検証結果、安定した判断レジストリを記録します。このチェックポイントをステージングまたはコミットしてはいけません。再開時にはライブ状態と照合します。

実行と統合

1. コーディネーターは薄く保ちます。コーディネーターが担うのは、確定した決定事項とその根拠、グラフの状態、ワーカーの受け入れと交代、デリバリー状態の昇格、統合、マージ、マイルストーンの完了です。詳細な調査、実装、修正、検証は、各タスクパケットに記録された能力ティアのワーカーが担当します。
2. 各ワーカーには、コンテキストが分離されたタスクパケットを、その依存関係とともに1つずつ渡します。課題または確認済みのロードマップ項目、必須のエンドポイント、設定済みの統合先、および該当するエビデンスを使って /deliver を実行します。選択したアプローチも渡し、/implement が再検討する必要がないようにします。このワークフローの /code-review fix-all というレビューのデフォルト設定をパケットに保持します。作業項目のデフォルトのデリバリー先は設定済みの統合先で、マイルストーンが共有シーケンスとリリース公開を担います。重要な選択はユーザーに委ねます。
3. 既存の PR が課題とプロジェクトのゲートを満たす場合は、それを採用します。所有者と範囲が明確な場合に限り、関連するローカル状態を採用します。不明確な状態、変更済みの状態、既存の状態、または無関係な状態は保持し、その旨を報告します。
4. 各 /deliver に、実装、公開、フィードバック、統合のループを任せます。作業項目を昇格させる前に、返されたリビジョン、動作、PR、デスティネーションのエビデンスを照合します。ネイティブな依存関係スタックには、完全な準備状況の確認とアトミックなマージを担うデリバリーオーナーを1人割り当てます。同じスタックに対する権限を競合するワーカーに与えたり、必須の修正レイヤーの下に不完全なプレフィックスをマージしたりしないでください。
5. 修正の検証は、変更した動作に焦点を絞ります。実装とレビュー修正が意図したヘッドに収束した後に限り、リポジトリの完全なローカルゲートを1回実行します。ただし、新たな重要なソース変更によって無効になった場合は除きます。完全なスイートを診断ループとして繰り返し使用しないでください。
6. 負荷の大きいフル CI は、リモートデバッガーではなく、最終的な昇格エビデンスとして扱います。必要な PR チェックと、すべての実行中レビュー用ツールが候補ヘッドに収束した後に限り、実行します。CI サービスが安全なキャンセルに対応している場合は、置き換えられた実行をキャンセルします。それ以外の場合は、避けられなかった無駄を記録します。その後のヘッド、PR ベース、トポロジー、またはレビューの変更により証明は無効になりますが、ベースブランチが先に進んでも無効にはなりません。
7. バッチを待たずに継続的に統合し、git-workflow のマージルールに従って、準備が整った PR またはスタックを順次マージします。スカッシュマージのたびに、マイルストーンの範囲とデフォルトブランチの状態を再取得します。更新されたリモートベースは、git-workflow が必要と判断した残りのブランチにのみマージし、該当するゲートを再実行します。レビューと CI のエビデンスは、現在の PR ヘッドに対してのみ有効です。
8. 実行中に新たな作業が見つかった場合、課題が外部からマイルストーンに追加された場合、またはマイルストーンのマージによって統合済みのリグレッションが発生した場合は、references/scope-changes.md を読みます。

ホストの共有容量の範囲内で、実装ワーカーとレビューワーカーを管理します。有用な作業が残っている間は実装ノードを稼働させ、スロットが空くまでレビュー軸のレーンをキューに入れます。一時的なスロット不足は、サブエージェントを利用できないことを意味しません。レビュー用サブエージェントがサポートされていない場合、回数を限定した再試行後も利用できない場合、またはエビデンスが不完全な場合は、実装ワーカーがそれらのレーンを直接完了し、マイルストーンレポートに代替対応を記録します。 すべての成果物のライフサイクル、判断、待機、ゲート、利用、再試行、やり直し、統合の各遷移を正規化してから、イベント台帳の ingest コマンドに渡します。 ホストアダプターがネイティブイベントからの変換を担います。このスキルにプロバイダーのトランスクリプトパーサーを追加してはいけません。 内部のデリバリーとレビューのループでは、バンドルされた決定論的な待機を delivery-wait の実行ルールに従って起動します。 外側のマイルストーンループは、オーケストレーションリファレンスに記載されたイベント駆動型の待機に従い、ワーカーまたはコマンドの完了を受動的に待ちます。また、遷移が返されるたびにチェックポイントを調整します。 リポジトリポリシーで必須とされる受動的な待機に対応できない場合は、起動をブロックします。

ブロッカーと完了

• ブロックされたノードとその依存ノードを隔離し、独立して実行可能なノードはすべて続行します。安全に進められることがなくなった場合にのみ一時停止します。ブロック中または未検証の作業があるマイルストーンを完了にしてはいけません。
• ホストのプラットフォーム制限の範囲内で、イベント駆動型の待機を通じて、レビュー、CI、イシュー、プルリクエストの一時的な状態を再試行します。利用可能な場合は、正確で安全な retry_at を使用します。レート制限中または判定待ちの状態は保留中であり、成功ではありません。
• 完了前にマイルストーン、イシュー、プルリクエスト、レビュー、CIの状態を再取得し、対象範囲内のすべての項目が証拠を伴って納品・クローズされていること、マイルストーンのPR、必須チェック、レビュースレッド、アクティブなレビュー・ツールの実行が保留中ではないこと、同期済みのデフォルトブランチが該当するプロジェクト全体のゲートを通過していることを確認します。該当するリビジョンに対するウォッチャーまたはCIの結果がその証拠となるため、ゲートを再実行してはいけません。失敗した場合は実行を再開します。
• 完了前に、現在の runId に対してイベント台帳の validate コマンドと summarize コマンドを実行します。イベント台帳のリファレンスに記載されている完了証拠に不備がある場合は、修正するか、スキーマに従って利用不可と明示するまで完了をブロックします。
• 作業項目と統合のゲートに合格した後、マイルストーンのリリース権限者、確定済みのリリース計画とバージョン、または決定論的なプロジェクトのバージョンポリシー、および最新の証拠を渡して /create-release を呼び出します。未解決の重要なリリース判断がある場合に限り、確認を求めます。このコマンドは、設定済みのリリース経路を通じてリリースの準備と公開を担います。必須リリースが保留中または失敗している間は、マイルストーンのデリバリーは完了しません。リリース経路がないプロジェクトでは、公開者を勝手に作ったり、リリースの成功を想定したりせず、具体的な判断が必要です。
• 必須のリリース結果が検証された後にのみ、マイルストーンを完了にします。この実行で作成したクリーンなマージ済みワークツリーだけを削除し、それ以外のワークツリーはすべて保持して報告します。

レポート

完了したとする各主張を、そのアクションと対象に対して返された結果と照合してください。リリースの成功は、クリーンアップやメッセージの配信を確認するものではありません。振り返りの質問を送信して確認応答を受け取っても、キューに追加されたことの確認にはなりません。配信が確認されていない場合は、レポートで直接質問するか、依頼済みと記述してください。必須の成果を検証し、任意の未確認の主張は省略するか、失敗を示唆しない形で未確認と明記してください。表や括弧内の記述を含め、レポート全体に適用してください。共通のライティングガイダンスについては、agent-writing を参照してください。

以下のすべての項目を網羅した、監査形式の要約を 1 つ作成してください。各項目名をラベルとして使用し、オーケストレーションポリシーおよびこのスキル独自の要件、機能、前提条件に関する用語（例：stack prefix、repository-owned prerequisite、fallback）をそのまま使用してください。リポジトリ監査と振り返りではこれらの用語が文字どおり照合されるため、言い換えると関連付けが失われます。項目の結果が欠落している場合や未確認の場合は、省略せず、その旨を記載してください。

• 初期および最終スコープ。スコープのずれも含めます。
• issue、worker/worktree、PR、squash-merge の対応関係。
• 各 PR のレビュー軸とレーンの対応、レーンのステータス、および単一エージェントへのすべてのフォールバックとその理由。code-review のレポート用語で記載します。
• 再利用したローカル状態または PR の状態。
• オーケストレーションポリシーのステータス、判断 ID と競合、worker のコンテキストモード、およびフォールバックとして明記した監視フォールバック。
• CI 統合に関する推奨事項。同じ内容が前提条件の問題にも含まれている場合でも、推奨事項として明記し、各 repository-owned prerequisite または現行 CI のフォールバックコストを記載します。
• イベント台帳のパスと完全性、介入チェックポイント、取得できなかったテレメトリーフィールド。
• 最終 PR head および統合済み default に対する検証とレビュアーの証拠。
• 必須の追加事項、延期されたフォローアップ、ブロッカー、残作業。
• 統合先、リリース結果、リビジョン／アーティファクトの証拠。
• クリーンアップまたは保持した状態、およびマイルストーンのクローズ状況。

マイルストーンが未完了の場合は、残作業と、完了に至るために必要な手順で締めくくってください。マイルストーンが完了している場合は、レポート内で /run-retro を実行するか尋ね、明示的な承認を得た後にのみ実行してください。