プロジェクトデリバリー

プロジェクトデリバリー は何をしますか？

バックログをmain上で完了まで実行します。すべてのチケットは1つのPRになり、リポジトリのGitHubレビュー自動化と人間によってレビューされます。あなたの仕事は、作業の流れを維持することです：チケットを開始可能になったらすぐに開始し、すべてのPRを健全に保ち、対応する価値のあるレビューフィードバックに対応し、親がマージされるにつれてスタックされたブランチをリベースし、チケットのステータスを正確に保ちます。

あなたはオーケストレーターです。状態を読み取り、決定し、委任し、記録を管理します。エージェントがすべてのコードを書き、コンフリクトを解決し、プッシュします。このチェックアウトではコードを編集したりリベースを実行したりしないため、メインプロジェクトフォルダーはクリーンなままで、すべての変更はトレーサブルです。

入力

$ARGUMENTS

• タスクファイル: /task-breakdown からのローカルの *.tasks.md（追跡対象外、通常 .rfcs/ のようなgit無視フォルダー内）。指定がない場合、そこおよび docs/rfcs/ を探します。複数存在する場合は確認を求めます。
• --parallel N: 同時に作業する最大エージェント数（全種類合計）。デフォルトは3。
• --max-stack N: PRスタックの最大深度。デフォルトは3。より深いスタックはより多くの作業のブロックを解除しますが、親が変更されたときのリベースが増加します。
• --auto-merge: main上のPRが pr-ready になったとき、GitHubの自動マージを有効にします（gh pr merge --auto をリポジトリの通常のマージ方法で使用）。GitHubはブランチ保護と必要な承認を引き続き強制します。デフォルトはオフ：人間がマージします。
• --once: 単一のパスのみ実行して終了します。これを使用して、例えば /loop 15m /deliver-project <tasks-file> --once のようにスケジュールでデリバリーを実行します（長時間のセッションを1つ開いたままにする代わりに）。

状態の保存場所

• トラッカー（Linear、Jira、GitHub Issuesなど） - 公開されたチケット（タスクファイルに Tracker: キーがあるもの）用。チケットが存在し、必要とされているかどうかの真実の情報源です：そこでキャンセル、削除、または再割り当てされたチケットはスキップされます。トラッカーのGitHub統合が既にそれを行っていない限り（最初のPRが開かれた後に確認し、それと戦わない）、チケットの進行に応じてトラッカー課題の状態を移行します。
• ローカルタスクファイル - メインプロジェクトフォルダー内。デリバリー状態の真実の情報源であり、実行中にそれを書き込むのはあなただけです：エージェントは読み取りますが、決して編集しません。ステータス: open → in progress → pr-draft → pr-open → pr-ready → pr-merged → done、および理由付きの blocked と canceled。スパイクは open → in progress → decision-proposed → decided → done になります。Branch / PR:（またはスパイクの場合は Decision:）を記入します。
• GitHub - PR状態用：開く、マージ、チェック、レビュー、マージ可能性。PRがマージされていれば依存関係はマージされたものとみなされ、ファイルに何と書かれていても同じです。
• ブランチ - この実行のPRを識別します：すべてのブランチは <username>/<project-slug>/<task-branch> です。したがって、この実行のPRは、ヘッドブランチが <username>/<project-slug>/ で始まるユーザーのPRです。これにより、再起動された実行がすべてを再び見つけられます。
• 実行ログ - タスクファイルの隣の <rfc-name>.run.md（ローカル、追跡対象外）。チケットステータスではないもの：実行中のエージェント、各スタックブランチの親ヘッドSHA、処理済みのコメントID、フィードバックラウンド、CI修正試行、エスカレーション、フォローアップ。 templates/run-log.md を使用します。失われた場合は、GitHubから再構築します。

references/github.md には、PR状態、レビュースレッド、チェックを読み取るための gh コマンドがあります。

1. プレフライト（最初のパスのみ）

以下のいずれかが失敗した場合は、明確なメッセージで停止します：

1. タスクファイルが正常：ID、ステータス、既存の依存関係、受け入れ基準、Project slug:、依存関係サイクルなし。
2. トラッカーにアクセス可能：チケットにトラッカーキーがある場合、トラッカーのコネクタが利用可能でなければなりません。キャンセルを確認し、状態を更新するために必要です。利用できない場合は、どのコネクタを有効にするかを伝え、ローカルファイルのみを使用して続行するオプションを提供します。
3. リポジトリの準備完了：クリーンなワーキングツリー、リモート、プッシュおよびPR権限で認証された gh、そしてmainがビルドされテストに合格すること。<username>（ユーザーの既存ブランチのプレフィックス、それ以外の場合は gh api user --jq .login）とブランチプレフィックスを特定します。
4. エージェントが無人で作業可能：バックグラウンドエージェントはこのセッションで毎回の権限プロンプトを表示するため、1つのプロンプトでチームが停止します。自動モード、またはgit（push --force-with-lease を含む）、gh、リポジトリのテスト、リント、ビルドコマンド、およびトラッカーコネクタの許可ルールを推奨します。
5. スキルが利用可能：implement-task と spike-task がエージェントにロード可能な場所にインストールされており、決定後の改善のために task-breakdown があなたに利用可能であること。
6. レビュー自動化：PRをレビューするGitHubワークフローを見つけ、そのチェック名とボットログインを記録します。これにより、レビューがいつ完了したか、どのコメントがそのワークフロー自身のものかがわかります。

次に計画を示し、1回の確認を得ます：チケット数、今開始できるものとスタックされるもの、並列度、最大スタック深度、自動マージの有無、そして各エージェントが完全なセッションであり実行が重要な使用量を消費するという正直な注意事項。その後、無人で実行します。

2. 各パス

これらを順番に実行します。スタックの底優先が重要です：親の修正やマージは、その子が何をすべきかを変更します。

a. 同期

Fetchを実行します。この実行のPR（ブランチプレフィックスで）を、状態、ベース、ヘッドSHA、チェック、レビュー決定、マージ可能性とともに一覧表示します。トラッカーから公開チケットをリフレッシュし、キャンセルされたものをスキップします。前回のパス以降に完了したエージェントのレポートを収集します（各レポートは RESULT ブロックで終了します）。調整：GitHubとタスクファイルが一致しない場合、PR状態についてはGitHubが優先されます。ファイルを修正します。

b. マージの処理

前回のパス以降にマージされたすべてのPRについて：そのチケットを pr-merged に設定し、統合が行っていない場合はトラッカー課題を完了に移動します。トラッカーがクローズされたことを示し、チケットのロールアウトステップが完了したら done に設定します。マージされたPRに直接スタックされているすべてのPRは、mainにリベースし、ベースをmainに変更する必要があります：影響を受けるスタックごとに1つのリベースエージェントを開始します（references/stacks.md を参照。エージェントにその絶対パス ${CLAUDE_SKILL_DIR}/references/stacks.md を渡します）。

c. 決定を前進させる

スパイクはその背後にあるチケットをゲートし、決定はユーザーのみが承認します。決定は計画を変更するためです。

• decision-proposed の各スパイクについて、ユーザーがそれを確認したことを確認します：質問、推奨事項と信頼度、提案されたバックログ変更（1行）、決定記録のパスを、更新の先頭に配置します。承認するか、別のオプションを選ぶか、スパイクを延長するよう依頼します。その間、他のすべてを動かし続けます。
• ユーザーは、このセッションで直接伝えるか、--once パスの間でタスクファイル内のスパイクを decided に設定（記録に選択されたオプションを記載）することで承認します。スパイクが decided になったとき：決定記録の Status: 行に承認を記録し、task-breakdown スキルの「スパイク後の改善」ステップを使用してバックログを改善し（ユーザーの承認はトラッカー同期をカバーします）、スパイクを done に設定します。その依存関係は、次のステップで開始可能になります。
• ユーザーがスパイクを延長することを選択した場合、それを open に戻し、Question: フィールドに絞り込まれた質問を設定します。

d. オープンPRを健全に保つ

オープンPRを各スタックの底から順に処理します。1つのブランチまたはスタックにつき常に最大1つのエージェントに制限し、誰かが修正している間に別のエージェントがブランチをリベースしないようにします。PRに作業が保留されている間、そのチケットは pr-open のままです。

1. 親が移動した。スタックされたPRの親に新しいコミットがある場合（そのヘッドSHAが子のために記録されたものと異なる場合）、子を親の新しいヘッドにリベースします。
2. ベースとの競合。GitHubがPRの競合、またはブランチ保護が最新の状態を要求している場合に古くなっていると報告した場合、リベースします。mainが移動しただけではリベースしません。それはCIとレビューを無駄に再トリガーします。
3. CIが失敗。失敗したログを読みます。不安定またはPRに関連しない（インフラストラクチャ、PRが触れないテストがmainでも失敗している）ように見える場合、失敗したジョブを1回再実行します。PRが原因の場合、失敗を項目としてフィードバックエージェントを開始します。2回の修正試行が失敗した後、チケットを blocked に設定しエスカレーションします。
4. レビューフィードバック。レビュー自動化のチェックが完了するまで待ちます。次に、未解決のすべてのレビュースレッドとまだ処理していないコメント（セクション3）をトリアージし、対応すべき項目と投稿する返信を含めてPRごとに1つのフィードバックエージェントを開始します。
5. 準備完了。チェックがグリーン、レビュー自動化が完了、未対応のフィードバックなし：チケットを pr-ready に設定します。そのベースがmainで --auto-merge がオンの場合、自動マージを有効にします。それ以外の場合は、人間によるマージの準備ができたものとして更新にリストします。

e. 新しいチケットを開始する

空いているエージェントスロットを、開始可能なチケットで埋めます。スパイクを優先します。スパイクは他の作業をゲートするためです。次にクリティカルパスのチケットです。

• スパイクは、open で依存関係が完了している場合に開始できます。references/agent-prompts.md のスパイクプロンプトを使用してスパイクエージェントを開始し、チケットを in progress に設定します。スパイクはPRを受け取ることはなく、何もスパイクにスタックしません。
• チケットは、open でトラッカーでキャンセルされておらず、依存するすべてのスパイクが done であり、他のすべての依存関係がマージ済みであるか、グリーンチェックと変更要求なしのオープンPRを持っており、すべての未マージ依存関係が単一のスタックライン上にある場合に開始できます。最上部の未マージ依存関係のブランチにベースを置くか、すべてがマージされている場合はmainにベースを置きます。--max-stack を超えないようにします。
• 2つの未マージ依存関係が異なるスタックにある場合、一方がマージされるまで待ちます。
• Files: が重複する2つのチケットを同時に実行しません。

ブランチ名を決定し（<username>/<project-slug>/<task-branch>、公開時には task-branch にトラッカーキーを含める）、チケットを in progress に設定し（統合が行わない限りトラッカー課題も同様）、references/agent-prompts.md のプロンプトを使用して実装者を開始します：汎用エージェント、バックグラウンド、Agent呼び出し時に `isolation: