rig-epic — 統合ブランチワークフロー
複数の項目からなるアーク（連続する作業）において、各項目を直接トランク（メインブランチ）に載せると一時的にランタイム契約が破損する可能性がある場合、子PRを共有の統合ブランチにスタックし、最後にそのブランチを一つのPRとしてスカッシュしてトランクにマージします。各子PRは、実際のステップとしてレビューされます。トランクへの納品は、一つのスカッシュされたリベースです。
設定
.rig/config.json を読み取ります（デフォルト値は括弧内に記載）。
tracker.provider—linear|github|none（none）。親/子項目の保存方法。noneの場合、項目はエピックの状態ファイル（後述）にのみ存在し、トラッカーへの呼び出しは行われません。tracker.team/tracker.project/tracker.ticketPrefix/tracker.githubIntegration。vcs.baseRef（origin/main）、vcs.defaultBranch（main）、vcs.protectedBranchMergeQueue（false）。sourceScope[0]—plan中に探索する場所。agents.architect/agents.reviewer（デフォルトrig-<role>）— 新しいコンテキストのreviewパネル用。
以下のスキルに委譲します：/rig-task（子ごと）、/rig-worktree（チェックアウト）、/rig-review + /rig-review fix（結合差分レビュー）、/rig-tidy（オプション）。
エピック状態ファイル（外部メモリの代替）
アクティブな各エピックは、リポジトリローカルのJSONファイル .rig/epics/<統合ブランチ名>.json で追跡されます。
{
"parent": "ABC-42 または tracker=none の場合はスラッグ",
"parentTitle": "…",
"integrationBranch": "abc-42-<スラッグ>",
"whyEpic": "どの子がどのようにインターリーブするか",
"children": [
{ "id": "ABC-43", "title": "…", "blockedBy": [], "branch": null, "status": "todo|merged" }
]
}
これが next/run/review/finish/prune が読み取る単一の真実源です。.rig/epics/ を .gitignore に追加してください（一時的な調整状態です）。親の推論（<PARENT> が省略された場合）：.rig/epics/*.json が1つだけ存在すればそれを使用し、0個または複数存在すればユーザーに問い合わせます。
インテントバナー： すべての呼び出しは、最初の1行としてモード、どのブランチをPRがターゲットにするか、何を行わないかを出力する必要があります。
rig-epic: <サブコマンド> — <アクション>。PRのターゲットは <ブランチ>。<行わないこと> は行いません。
status（デフォルト、レポートのみ）
エピック状態ファイルを読み取ります。レポート内容：統合ブランチ + vcs.baseRef からのコミット数；オープンな子PR（gh pr list --base <統合ブランチ>）とその状態；各子のトラッカーステータス（トラッカーがある場合）；残っているマージ済み/削除済みワークツリー（/rig-epic prune を提案）；および1行の推奨事項（子PR X をオープン、/rig-epic next の準備完了、または /rig-epic finish の準備完了）。何も変更せず、何も起動しません。
plan <FEATURE>
機能を親 + 3〜8個の子に分解し、状態ファイルを書き込み、その後 start にチェインします。
作業が真にエピックの形をしている場合のみ使用してください（子がインターリーブする — 少なくとも1つの子のランタイム契約が、別の子が部分的に完了していることに依存している）。項目が独立しており、それぞれが単独でトランクに載せられる場合は、停止してユーザーに /rig-sprint plan を実行するよう伝えてください。同じ分解結果で、統合ブランチは不要です。
手順
- コンテキストを読む。 プロジェクトに製品/仕様ドキュメントがあれば読む（不明な場合は尋ねる）；コードベースを探索する（
sourceScope[0]）。トラッカーが設定されている場合は、最初に重複に近い項目がないか検索する。 - エピックであることを確認する（上記のインターリーブテストに従って）。そうでない場合 →
/rig-sprint planに送る。 - 親を作成する。
tracker: linear/github→ 親項目を作成する（設定からのチーム/プロジェクト）；説明には概要、なぜエピックなのか、計画された子を含める。tracker: none→ 親は状態ファイルにのみ記録されるスラッグとタイトル。
- 各子を依存関係エッジと共に作成する。
- 1つのエージェントセッションに十分小さい（1〜3ファイル）；具体的でテスト可能な受け入れ基準；基盤となる作業を最初に。
- すべての実際の依存関係に対して
blockedByを記録する — これがnextが次のブロック解除された子を選択するために読み取るものです。これがないと、選択は宣言順にフォールバックし、インターリーブされたエピックを誤って扱います。 - トラッカーモード：トラッカーのネイティブな親/ブロック関係を設定し、それらを状態ファイルにミラーリングする。
none：状態ファイルのみ。
- サマリーテーブルを表示する（ID · タイトル · 依存関係）。
start <PARENT>にチェインする —planは計画して開始するものです。停止して尋ねないでください。start後に停止する。 統合ブランチ、子、次のステップ（1つの子には/rig-epic next、ループには/rig-epic run）を報告する。runを自動開始しないでください — 実行は明示的なオプトインです。
start <PARENT>
事前準備：git fetch origin；親と少なくとも1つの子が存在することを確認する（トラッカー内、または none の場合は引数として）。
- 統合ブランチ名：
<親スラッグ>-<タイトルスラッグ>（ケバブケース、例：abc-42-agent-as-definition）。 vcs.baseRefから統合ブランチをカットする（ローカルチェックアウトなし）：
非破壊的。ブランチが既に存在する場合はそのままにする（上書きしない — 進行中の作業を破壊する可能性があります）。git fetch origin git push origin <vcs.baseRef>:refs/heads/<統合ブランチ>.rig/epics/<統合ブランチ>.jsonを書き込む（上記のスキーマ）、親、なぜエピックなのか、すべての子 +blockedByを含む。これにより、各/rig-task <子>がトランクではなく統合ブランチをターゲットにします。- トラッカーが設定されている場合、各子に「統合ブランチ：ターゲット
<統合ブランチ>、トランクではありません」というメモを追加して、次のエージェントがこのスキルを再読しないようにし、親が「進行中」であることを確認する（適応的：まだ開始されていない場合のみ移動；ライブ統合が行った場合は延期）。子は/rig-taskのステップ1から自身の「進行中」ステータスを取得します。 - セッションに名前を付ける `