GravionLabs/deliver

オープンなPBIとバグ（作業アイテム = pbi または bug ラベルが付いたオープンIssue；バグは同じループを実行、ブランチタイプは fix、Closes #<番号>）を次々とデリバリーします：サブエージェントが実装し、サブエージェントがレビューし、このセッションがPRを開き、CIを待ち、マージします。すべてのハーネス（Claude Code、OpenCode、Copilot CLI）で同じ手順です。状態はGitHubのみに存在するため（Issue、サブIssue、ブランチ、PR）、実行はいつでも停止でき、/deliver <番号> で中断したところから続行できます。ハードゲートは release/next のルールセットです：赤または欠落した必須チェックがあると、このセッションが何をしてもマージをブロックします。

入力

help（または --help、-h）：references/help.md をそのまま出力し、それ以外は何もしません。

/deliver status --milestone <名前>：ステータスブロック（## Status block）を出力して停止し、デリバリーは行いません。

/deliver <番号> [<番号> …] [--milestone <名前>] [--unattended] [--inline] [--max <n>]：各番号はPBI、バグ、機能、またはエピックです；--milestone <名前>（リリース、M<n> またはレガシータイトル）は、そのマイルストーンのオープンな作業アイテムを追加します（マイルストーンを1回バッチ読み取り（pwsh <skill-dir>/../github-milestone/scripts/Get-Milestones.ps1 -Mode issues -Name <名前> -State open：REST、全ページ、PRなし；github-milestone ルックアップは M4 をタイトル M4 に、または close 後は M4 (0.2.0) に解決します；返されたリストをラベル pbi、bug でフィルタリングします）、さらにその中のフィーチャーとエピック以下の作業アイテムも含みます）。その読み取りの milestone.title が gh issue create --milestone のタイトルです； <キー> は M<n> またはサブ番号 M<n>.<m>（レガシー：タイトル）で、状態ファイルとヒントに名前を付けます。不足している場合は一度確認します。--max <n> は n 個のデリバリー済み、ブロック済み、または一時停止済みのPBIで停止し、レポートを出力します（scripts/Invoke-DeliverLoop.ps1 は新しいセッションごとに --max 1 を使用、references/loop.md）。

• インタラクティブ（デフォルト）：一時停止ルールがチャットでユーザーに確認します；ブロックされたPBIは、再試行、スキップ、または指示を確認します。
• 制御セッション：deliver.loopThreshold（デフォルト3）より多くのPBIがある場合のインタラクティブモード、例：--milestone ごと：ここではデリバリーせず、Invoke-DeliverLoop.ps1 を起動し、決定用のシンセッションとして留まります（references/control.md）。--inline はすべてをこのセッションでデリバリーします（ステップ1から9）。--no-preflight は開始3をスキップします。
• --unattended（claude -p、opencode run、copilot -p）：決して確認しません。一時停止はIssueにコメントし、needs-decision ラベルを追加し、それに依存しない次のPBIに進みます。

開始

1. gh auth status が機能し、リポジトリに release/next があります。
2. gh api repos/{owner}/{repo}/rules/branches/release/next --jq '.[].type'：出力に required_status_checks がない場合 → 赤いCIはここではマージ可能であると警告し（github-release のルールセット）、続行します。
3. 事前飛行（--no-preflight でスキップ）：pwsh <skill-dir>/scripts/Test-DeliverPreflight.ps1 -Harness <claude|opencode|copilot> [-Unattended] -Text はチェックごとに1行出力します（ok / fixed / action needed）：スタックスキル、許可リスト（git、gh、pwsh <skill-dir>/scripts/*、AGENTS.md の検証コマンド；ハーネスごとのエントリ：references/permissions.md、そうでなければ無人実行はプロンプトで停止します）、古いワークツリー；反応は references/preflight.md にあります。引用符で囲まれた $(…) なしでコマンドを記述します；許可チェックはそれらを透過できません。
4. 進行状況イベント：AGENT_EVENTS_RUN がない場合、pwsh <skill-dir>/scripts/Report-Progress.ps1 -Type run.started -Source session を実行し、出力された実行IDを保持します。以降のすべての呼び出しに -Run <id> を追加します（step.finished、attention、issue.finished、run.finished）：Bash呼び出しはシェル状態を共有せず、AGENT_EVENTS_RUN をプレフィックスとしても許可リストと一致しません。すべての進行状況行、注意理由、および終了は Report-Progress.ps1 を通過します；これはセッションが実行されている任意のターミナルにそれらを表示します（references/terminal-backends.md）。

ステップ

チャットにステップごとに1行出力します：#<番号> <ステップ>: <結果>（#12 review: 1 blocking → fix 1/2）。各行を報告します：pwsh <skill-dir>/scripts/Report-Progress.ps1 -Type step.finished -Issue <番号> -Step <ステップ> -Result "<結果>" [-Pr <url>]。また -Type attention（-Kind pr_opened と -Pr <url> はステップ6の後、review_fix はレビューまたはCIラウンドが修正ラウンドを開始するとき、ci_red はステップ7が赤のとき；-Reason）：ループの通知はこれらのイベントからのみ来ます。一時停止、ブロックされたPBI、またはユーザーを必要とするポイント：代わりに -Type attention（-Kind paused、blocked、または needs_you、-Reason）を使用します。各PBIの後に -Type issue.finished -Issue <番号> -Outcome <結果>。

チャットが名前を付けるすべてのPRとIssueは、その完全なURL（https://github.com/<owner>/<repo>/pull/<n>、.../issues/<n>）として記述され、裸の #<n> としては記述されません：裸の番号はターミナルでリンクになりません。これは進行状況行、ユーザーへの質問、およびレポートに当てはまり、特にユーザーがマージする必要があるリリースPR（ステップ9）に当てはまります。URLは gh（html_url）から取得し、メモリから作成しないでください。

1. 選択。 gh api repos/{owner}/{repo}/issues/<nr> --jq '{number,title,state,labels:[.labels[].name],body}' をすべての番号とそのサブIssue（github-issue references/sub-issues.md、PBIとバグまで再帰的に）に対して実行します。すべての番号とマイルストーンのオープンな作業アイテム（pbi または bug）を収集し、重複を削除し、needs-decision がないものを保持します（本文にADR基準があるものは #<番号> select: decision, write the ADR with adr と報告されます）；それらのブロックバイリンクによってすべての間で順序付けられ、同順位は引数の順序を維持します。--milestone の場合、マイルストーンのフィーチャーまたはエピックを介して到達したが、マイルストーンがないか別のマイルストーンを持つPBIまたはバグはデリバリーされません（#<番号> select: outside M<n>, skipped、ヒント：マイルストーンを設定、github-issue references/milestones.md）；--milestone なしの /deliver <feature> はそのすべてのPBIをデリバリーします。ブロッカーがまだオープンでセットに含まれていないPBIは待機し、報告されます（マイルストーン外のブロッカーは決してデリバリーされません）。needs-refinement があるPBIまたはバグ、または再現手順や受理基準がないバグはスキップされます（#<番号> select: needs refinement, skipped、ヒント planner refine <nr>）；そのようなアイテムに対する /deliver <nr> は拒否します。無人モードでは、interactive を持つPBIはスキップされます（#<番号> select: interactive, skipped、ヒント /deliver <nr> in a session）；インタラクティブモードはそれをデリバリーします（フィーチャー、エピック、またはマイルストーンを介しても）。release-test が付いたオープンPBI（マイルストーンのRCテスト）は作業として選択されず、ステップ1から8および制御セッションでも選択されず、interactive または明示的な <番号> でも選択されません：#<番号> select: release test, left for step 9（前にオープンアイテムがある場合：release test, waits for <n> open items；待機中、needs youではない；references/loop.md）。ステップ9と人間のためにオープンのままになります（RCテストはRCで実行されます）。別のセッションがクレームしたPBIをスキップします（#<番号> select: claimed, skipped）、古いクレームを引き継ぎます（references/claim.md）；PBI自体に対する /deliver <番号> はクレームに関係なくそれを続行します。次に来るPBIをアナウンスし、クレームします：gh issue edit <番号> --add-assignee @me；選択行はそのティアとモデルを名前付けます（#<番号> select: next (tier standard → sonnet/medium)；Tier: 行がない場合 tier from size M または default；references/roles.md）。
   • PBIのないフィーチャーまたはエピックの子：このセッションで planner（インタラクティブ）と grill-me をロードし、Issueを作成してから再選択します。無人モード：コメントして needs-decision ラベルを付けます。
2. 再開。 ブランチ <type>/<nr>-<slug>（github-issue）。git ls-remote --heads origin <branch> と gh api "repos/{owner}/{repo}/pulls?head=<owner>:<branch>&state=open" --jq '.[].number'（ヘッドには所有者プレフィックスが必要）：既存のブランチは続行され、既存のPRはステップ7にスキップします。
3. 実装。 新しいコンテキストを持つサブエージェント：「implementation をロード、ロール implement。PBI #<番号>（バグ：最初に diagnose をロード、次に implementation）を origin/release/next から <branch> 上の自分のワークツリーで実装します（既存のブランチ：それに切り替えてリベース）。受理基準：<Issueから>。コミットし、プッシュし、最大10行で報告します：done または blocked、コミット、テスト実行、および notes[]（1行に1つ）；一致する specMap エントリでspec変更がない場合、no spec change needed: <spec> — <reason> というノートを返します（implementation references/specs.md）。」
4. レビュー。 新しいコンテキストを持つサブエージェント：「code-review をロード、ロール review。git diff origin/release/next...origin/<branch> をこれらの受理基準に対してレビューします：<基準>。governance を使用：Get-GovernanceMatches.ps1 -Head origin/<branch> を実行；Issueラベル <ラベル> と実装者の notes[] <ノート>。読み取り専用：既存のチェックアウトで stash、checkout、switch、または commit を一切行わない；ファイルが必要な場合は、自分の一時的なワークツリーを使用します。JSONのみを返します：code-review の review.schema.json に従った結果（blocking[] には file、line、title、why；notes[]、最大5つ）に加えて unmet[]（満たされていない基準）。」ブロッキングな発見と未達成の基準のみがカウントされます。このセッション（サブエージェントではない）は、毎ラウンド後にファイル <git-common-dir>/.agents/state/review-<nr>.json を書き込みます（git rev-parse --git-common-dir、すべてのワークツリーから同じファイル、決してコミットされません）、前のラウンドを上書きします：{ pbi, branch, sha, round, unmet, review }、sha = git rev-parse origin/<branch>、round = 1ベースのレビューラウンド、review = サブエージェントの結果；スキーマは schema/deliver-review.schema.json。また pwsh <skill-dir>/../code-review/scripts/ConvertTo-Findings.ps1 -Review <結果 with unmet> -Sha <sha> -Worktree <pbi-worktree> は <pbi-worktree>/.agents/state/findings.json をpoimen用に書き込みます（決してコミットされず、ローカルで除外；references/findings.md）。
5. 修正。 何かがカウントされます：新しいコンテキストを持つサブエージェントは implementation をロール fix でロードし、自分のワークツリーを <branch> に切り替え（git fetch origin <branch>、git switch -C <branch> origin/<branch>）、それらの発見（blocking[] と unmet[]）を正確に取得し、コミットしてプッシュします。その後、ステップ4に戻ります。PBIごとに最大2ラウンドの修正ラウンドで、レビューとCIで共有されます；3回目は一時停止です。
6. PR。 github-pull-request（タイトルはレベルプレフィックスなしのIssueタイトルに (#<番号>) を追加）を issue_number、branch: <branch>（作業は別のワークツリーからプッシュされ、このチェックアウトはそのまま）、review_notes（ステップ4の notes[]）、governance 付きで spec_notes（実装者の notes[] 行で no spec change needed: で始まるもの）およびサブエージェントのテスト結果を使用して作成します。
7. CI。 gh pr checks <pr> --watch --required --interval 60 を直接実行します（各ポーリングはGraphQLクエリであり；デフォルトの10秒は予算を消費します）、パイプや出力フィルター（tail、head、grep など）なしで、ウォッチの進行状況がセッションに到達するようにします。
   • この変更による赤（差分のファイルでのテスト、リント、またはビルドエラー）：修正ラウンド（ステップ5）、その後ステップ4と7を再度実行します。
   • 別の理由による赤（フレーク、release/next でも赤）：PRにコメントし、PBIはブロックされます。
8. マージ。 両方のモードで確認なし：最後のレビューにブロッキングな発見も未達成の基準もなく、必須チェックが緑の場合。gh pr merge <pr> --squash --delete-branch、次に gh issue close <nr> --comment "Delivered in #<pr>"（Closes は release/next では発火しません）；PBIのオープンなレガシー [Task] サブIssueもそれと一緒に閉じられます（github-issue references/sub-issues.md、「Legacy Task issues」）；次に gh issue edit <nr> --remove-assignee @me。サブエージェントのワークツリーとブランチをこのスキルのスクリプット scripts/Remove-PbiWorktrees.ps1 を使用してクリーンアップします（スキルディレクトリ ~/.claude/skills/deliver/ グローバル、.claude/skills/deliver/ プロジェクトインストール）、リポジトリから実行：pwsh <skill-dir>/scripts/Remove-PbiWorktrees.ps1 -Pr <pr> -Issue <nr>；#<番号> cleanup: <n> removed を出力し、その left エントリ（パスまたはブランチ、理由、コマンド）をレポート用に保持します。次のPBI：ステップ1。
9. リリース。 --milestone がある場合のみ、レポートの前（--max の後も）、選択するPBIが残っていない場合。マイルストーンを1回読み取ります、Get-Milestones.ps1 -Mode issues -Name <名前> -State all（オープンとクローズド）；オープンワークチェック、マーカー、ラウンドカウント、およびクローズドIssueの基準はそのリストから来ます。release-test のIssueを除いて、その中に pbi または bug ラベルが付いたオープンIssueはありません（ブロック、一時停止、待機、スキップされたものはありません）；RCテストは決してブロックしません。
   • マイルストーンのクローズドPBIまたはバグに needs-decision ラベルが付いている場合、それはラウンド3リリースレビューの一時停止マーカーです：レビューをスキップし、release: paused in round 3, waits for a decision を出力します。
   • リリースレビュー（references/release-review.md）：新しいコンテキストを持つサブエージェントは code-review、ロール review をロードし、git diff origin/main...origin/release/next をマイルストーンのクローズドPBIとバグの受理基準に対して、PBI間の一貫性に焦点を当ててレビューし、review.schema.json に従ってJSONを返します。読み取り専用（既存のチェックアウトで stash、checkout、switch、または commit は一切行わない；ファイルが必要な場合は自分の一時的なワークツリーを使用）；このセッションは <git-common-dir>/.agents/state/release-review-<キー>.json を書き込みます。
   • ブロッキングな発見：マイルストーンごとに1つの発見につき1つの [Bug] fix: … Issue（インタラクティブ：それらを表示して最初に確認）、リリースPRなし；release: <n> blocking → #a, #b を出力します。マイルストーンごとに最大2ラウンドのリリースレビュー；ブロッキングな発見がある3回目は一時停止であり、そのマーカーと2つの進め方を示すコメントで記録されます（references/release-review.md、「Pause marker」）。
   • クリーン（ブロッキングなし）：RCをカットし、release-test Issueに投稿し、古いものを閉じます（references/release-review.md、「RC test」）；release.test.gate: true は、Issueが閉じられるまでそこで停止し needs you: RC test <Issue URL> と表示します。そうでなければ github-release をロードし、release_review_notes（notes[]、最大5つ）を指定して finish を実行します：release/next から main へのリリースPRを開くか（auto_merge: false）、既存のものを報告します；main が release/next の祖先でない場合に停止します（最初にバックマージ、github-release）、その停止を報告します。release: <n> blocking → #a, #b を出力します。