merge-discipline

マージ規律

内部共有スキル — マージ時の規律に関する唯一の信頼できる情報源です。5 つのパートを A → B → C → R → D の順に実行します：OpenSpec アーカイブ関連付けゲート（パート A）＋リベース／競合の事前チェック（パート B）＋カバレッジゲート（パート C）＋PR コードレビュー（パート R、強い依存関係 pr-code-review）＋スカッシュの判断と先端の固定（パート D）。このスキルを参照するワークフローは、フロントマターの dependencies でこれを宣言し、起動時に見つからない場合は中止します。

前提スキルのチェック

読み込み時にフロントマターの dependencies を確認します。1 つでも見つからない場合 → 以下の不足通知を出力して中止します（暗黙の機能縮退はしません）。

不足通知

⚠️ merge-discipline is missing a strong dependency and cannot run

【Missing skill(s)】
- <name>: <one-line purpose>

【Why it's needed】
merge-discipline strongly depends on:
- `pr-code-review`: Part R — multi-perspective PR review with ≥80 confidence filter before tip-pin merge

【Install】
Install each missing skill by name (preferred):
  npx skills add FuDesign2008/open-skills -g --skill <name> --yes
Example for this skill's dependency:
  npx skills add FuDesign2008/open-skills -g --skill pr-code-review --yes
Or install every open-skills skill:
  npx skills add FuDesign2008/open-skills -g --skill '*' --yes

Re-trigger merge after installing.

不足しているスキルが複数ある場合は、不足している名前ごとに npx skills add … --skill <name> --yes の行を1 行ずつ出力します（'*' のみを表示してはいけません）。

適用される場合

保護ブランチへのあらゆるマージ（glab mr merge／gh pr merge／git merge <target>）が対象です。ワークフローのブランチクローズアウトの判断による場合でも、ユーザーによる直接のマージコマンド（「MR をマージ」／「合并」）の場合でも、AI がマージ呼び出しを準備する場合でも同様です。「ブランチを維持」／「開発を続行」は対象外です。

ホストが feature-branch-closeout を使用する場合、クローズアウトメニューはそのスキルが管理します。このスキルはマージが選択された後（または直接のマージコマンドの場合）にのみ実行します。ここでメニュー全体を再定義しないでください。

マージ時の実行順序：パート A（アーカイブゲート）→ パート B（リベース）→ パート C（カバレッジ）→ パート R（PR コードレビュー）→ パート D（スカッシュの判断＋先端の固定）→ マージ。 アーカイブ作業がリベース／CI の後回しにならないよう、パート A を最初に実行します。リベースによってソースの先端が変わるため、新しい先端に対してパート C／R／D を再実行する必要があります。

---

パート A — OpenSpec アーカイブ関連付けゲート

マージしてからアーカイブすることを防ぎます。実装が保護ブランチに取り込まれた一方で、OpenSpec の差分仕様／アーカイブが後続のドキュメント PR にしか存在しない、という事態を防止します。

関連付け（いずれかに該当すれば関連付け済み）

1. 差分への該当：PR またはブランチの差分に、openspec/changes/archive/ 配下ではない openspec/changes/<name>/ 配下のパスが含まれています。
2. セッションへの該当：セッションに紐づく OpenSpec の変更名が、openspec list で引き続きアクティブとして表示されています（アーカイブされていません）。

判断表

状態	アクション
関連付けなし	続行 → パート B
関連付け済みで、変更がすでにアーカイブ済み（openspec/changes/archive/… 配下にのみ存在し、openspec list にはない）	続行 → パート B
関連付け済みで、変更が引き続きアクティブ	マージをブロックします。変更名を明示します。同じソースの先端でアーカイブ（メイン仕様を同期し、openspec/changes/archive/ に移動）するよう求め、その後、パート A からマージを再開します。パート B／C／D やマージコマンドは実行しないでください。

厳守事項

• ユーザーによる直接のマージコマンドでも、このパートを必ず実行します。暗黙のスキップは禁止です。
• ユーザーが強制的に続行できるのは、以下のテンプレートを使ってスキップを明示的に記録する場合のみです。デフォルトではブロックします。
• 変更が関連付け済みでアクティブな間は、マージ後に別のアーカイブ MR を作成することを推奨しないでください（パート D の戦略 B — 復旧時のみ）。

検出方法（例）

# Diff hit (GitHub example — adapt for platform)
gh pr diff <id> --name-only | grep -E '^openspec/changes/[^/]+/' | grep -v '^openspec/changes/archive/'

# Session hit
openspec list --json   # active names; compare to session-bound change

記録用テンプレート

場所：PR の説明と design.md の Verification Notes（存在する場合）。

ケース	テンプレート
ユーザーが明示的にスキップ	【OpenSpec archive 门控跳过】用户显式跳过，关联 change 仍为 active。时间：<ISO>。决策人：用户。change：<name>。
暗黙の見落とし（ゲートを実行せずにマージ）	【OpenSpec archive 门控漏跑】合并已发生但 Part A 未运行。时间：<ISO>。漏跑阶段：<合并前/合并后>。

危険な兆候

• 「ステージ 8 ですでに後でアーカイブすると言った」または「マージ後にドキュメント PR を作成する」という理由でマージする。
• PR の差分に openspec/changes/<name>/ が残っている状態で、直接の「MR をマージ」に対してパート A をスキップする。
• オープンで関連付け済みの MR に対して、戦略 B を通常の手順として扱う。

---

Part B — リベース／競合の事前チェック

動いているターゲットへの盲目的なマージの失敗を防ぎます。ユーザーが「マージ」と言う頃には、ターゲット（release/*、main、…）はたいてい更新されています。チームメイトが自分の作業をマージしているためです。確認せずにマージすると、プラットフォーム側で失敗する（mergeable=false）か、最新のコミットより古い状態で気付かないままマージされます。この Part では、ユーザーが確認を求めるのを覚えていなくても、AI がその状況を提示し、リベースを提案します。

検出

git fetch origin <target-branch>
BEHIND=$(git rev-list --count HEAD..origin/<target-branch>)
BASE=$(git merge-base HEAD origin/<target-branch>)
CONFLICTS=$(git merge-tree "$BASE" HEAD origin/<target-branch> | grep -c "^changed in both")

<target-branch> = MR/PR のベースブランチ（プラットフォームの CLI 経由で取得）またはユーザーが指定したマージターゲットです。

判断マトリクス

状態	アクション
BEHIND=0 and CONFLICTS=0	問題なし — Part C に進みます
BEHIND>0 and CONFLICTS=0	「ターゲットが N コミット先行しています。リベースは競合なく適用できます」と報告 → ユーザーの確認を待ちます
CONFLICTS>0	「ターゲットが N コミット先行しており、約 M 個のファイルで競合します」と報告 → ユーザーの確認を待ちます

確認なしで自動リベースはしません。リベースはソースブランチを書き換え、CI を最初から再実行するため、その判断はユーザーに委ねます。

確認後 — リベースを実行（ソースブランチのみ）

ソースはユーザー個人の修正ブランチ（fix/jira-fix-…）であり、チームのポリシーでは強制プッシュが許可されています。保護対象のターゲットがこの Part によって書き換えられることはありません。

git rebase origin/<target-branch>
# On conflict: delegate to git-conflict-resolve skill (mode=rebase — per-commit resolution)
git push --force-with-lease origin <source-branch>

git-conflict-resolve を利用できない場合、またはユーザーが中止した場合は停止します。作業ツリーはリベース途中の状態のままにします（中止するには git rebase --abort を実行します）。人間による解決が必要です。

適用範囲の境界 — この Part は CI を待ちません

--force-with-lease によるプッシュ後、この Part は終了します。「リベース済み、PR を更新しました。CI を再実行中です」と報告し、ワークフローに制御を戻します。CI によるゲート判定と実際のマージは、ワークフローの通常のクローズ処理（Part C → Part D → マージ）で行います。ユーザーは CI が成功した後に戻ってきます。通常のレビュー後のマージと同様です。この Part はリベースによる修復ツールであり、CI を通してマージを進めるオーケストレーターではありません。

ループの上限

マージ試行ごとにトリガーされるリベースは最大 1 回です。CI を待っている間にターゲットが再び更新された場合、次のマージ試行では Part A から再開して再検出します。上限があるため、無限には繰り返されません。

注意事項

• 「CI はすでに成功している」ことを理由に、この Part を実行せずにマージすること（成功しているのは古い先端の状態であり、ターゲットは更新されています）。
• リベース後、新しい先端に対する Part D の祖先チェックが通る前に、マージ完了と報告すること。

---

Part C — カバレッジゲート

Part C はマージの意図が示された時点で開始します。デフォルトでは、アナライザーを自動実行しません。

1. プロジェクト設定を解決する

AGENTS.md、次に CLAUDE.md をスキャンし（最初に見つかったものを優先）、次の行に一致する設定を探します（キーの大文字・小文字は区別しません）。

coverage-gate:\s*(always|never|ask)\b

値	動作
(未設定)	ask として扱います
ask	マージのたびにユーザーに尋ねます。このマージのカバレッジを実行するか、スキップするかを確認します。自動実行してはなりません
always	尋ねずにゲートの手順を実行します（アナライザーを利用できる場合）
never	アナライザーをスキップし、プロジェクト設定の留痕を書き込み、Part R に進みます

2. 事前検出（実行すると決定した場合のみ）

test-coverage-analyzer が利用可能であれば、ゲートの手順に進みます。見つからない場合は「ゲートを利用できません：test-coverage-analyzer が検出されませんでした」と出力し、環境ギャップの留痕を書き込んだうえで、マージを続行するかどうかをユーザーに判断してもらいます。

3. ゲート手順（判定が run の場合のみ）

独立した Bash 権限でアナライザースクリプトを実行します。

1. --base を構築する（上から順に試し、最初に成功したものを使用します）。

   • MR/PR：gh pr view --json baseRefName -q .baseRefName / glab mr view <iid> -F json | jq .target_branch → --base <target>（ブランチ名のみ。スクリプトの validate_ref が origin/ を追加します）
   • 失敗／detached HEAD／リモートなしの場合：--base を省略し、スクリプトの5段階フォールバックに依存します。「明示的な base がないため、MR の差分が 0 と誤判定される可能性があります」と警告します
   • マルチリポジトリの MR：リポジトリごとに、それぞれの --base を指定してゲートを実行します。いずれかのリポジトリで失敗した場合は、全体を一時停止します

2. スクリプトを呼び出す（パラメーターの仕様を確認するため、まず test-coverage-analyzer の SKILL.md を読みます）。 python3 "<SKILL_DIR>/scripts/analyze_coverage.py" "<project-root>" [--base <target>]

3. 判定マトリクス：

   結果	🤖 自動	👤 手動
   ✅ レポートが生成され、カバレッジがしきい値を満たしている	Part R（PR コードレビュー）に進みます	合格と判断し、ユーザーに再確認を求めて待機します
   ⚠️ カバレッジがしきい値を下回っている	一時停止してレポートを出力し、ユーザーの指示（強制続行／テスト追加／中止）を待ちます	同じ
   💥 クラッシュ／レポートなし／終了コード 1	ゲート失敗として扱い、一時停止します	同じ
   📭 テストコードなし／合格率 0％	レポートを提示し、ユーザーの判断を待って一時停止します	同じ
   🕳️ Should-run なのにゲートが実行されず、マージされた（暗黙の未実行）	マージを一時停止し、ゲートを再実行します。すでにマージ済みの場合は、未実行の記録を残します	同じ

Should-run とは、設定が always の場合、または設定が ask でユーザーが実行を選んだ場合を指します。設定が never の場合や、ask でユーザーが明示的にスキップした場合は、暗黙の未実行には該当しません。

記録テンプレート

場所：PR の説明と design.md の Verification Notes。

ケース	テンプレート
ユーザーが明示的にスキップ	【カバレッジゲートのスキップ】ユーザーが明示的にスキップしたため、test-coverage-analyzer は実行されていません。時刻：<ISO>。決定者：ユーザー。
プロジェクト設定が never	【カバレッジゲートのスキップ】プロジェクト設定 coverage-gate: never。時刻：<ISO>。決定者：プロジェクト設定。
環境の不足（スキルが見つからない）	【カバレッジゲートのスキップ】test-coverage-analyzer スキルが見つからず、ゲートを利用できません。時刻：<ISO>。決定者：システム（環境の不足）。
暗黙の未実行	【カバレッジゲートの未実行】マージ済みですが、ゲートが実行されていません（実行すべきところ実行されませんでした）。時刻：<ISO>。未実行の段階：<マージ前／マージ後>。

---

Part R — PR コードレビュー（強い依存関係）

PR レビューなしのマージを防ぎます。カバレッジや CI が成功していても、複数の視点と二軸のレビューで検出できる、確度の高い欠陥が差分に残っている可能性があります。

1. pr-review-gate の設定を解決する

AGENTS.md、次に CLAUDE.md を検索し、最初に一致したものを使用します。

pr-review-gate:\s*(always|never|ask|non-code-light|auto)\b

値	動作
(未設定)	auto として扱います（内容に応じた深度 — 対象の分類 + 規模／リスクに応じたエスカレーション）
always	depth=full で pr-code-review を実行します
auto	内容に応じた深度：対象を分類し（§2）、規模／リスクに応じてエスカレーションします（§2.5）。エスカレーション条件に該当しない場合は light、いずれかに該当する場合は full（アプリケーションコードを含む）です
never	pr-code-review をスキップし、プロジェクト設定によるスキップの記録を残して、Part D に進みます
ask	ユーザーに、このマージで full／light／スキップのどれにするか尋ねます。自動で選択してはいけません。スキップする場合は、ユーザーが明示的にスキップした記録が必要です
non-code-light	PR の対象を分類します（§2）。アプリケーションコード以外の場合は depth=light、アプリケーションコードの場合は auto と同じ規模／リスクの段階的判定を適用します

2. PR の対象を分類する（必要な場合）

設定が non-code-light、auto、未設定の場合（または ask でユーザーが light を選んだ場合）、reference.md「アプリケーションコード以外の対象」にある許可／拒否テーブルを使用して、オープン中の PR/MR の 三点比較で変更されたパスを分類します。

• すべてのパスが許可リストにあり、拒否リストには該当しない → アプリケーションコード以外
• 拒否リストに該当するパスがある（または混在している） → アプリケーションコード

2.5 規模／リスクのエスカレーション

サーフェスの分類後、設定が auto（または未設定）の場合、あるいは設定が non-code-light かつ サーフェスがアプリケーションコードの場合に適用します。（non-code-light ＋ アプリケーションコード以外の場合は、この表を使わず light のままです。）いずれかの条件に該当した場合、depth=full を強制します。

シグナル	ソース	ルール
大規模な差分	三点差分の統計	変更行数の合計が 400 を超える または 変更ファイル数が 20 を超える → full
破壊的変更のシグナル	PR のタイトル／説明／コミットメッセージ、大文字小文字を区別しない	migration、schema、breaking、API contract、deprecat に一致 → full
失敗後の再エントリー	この tip における Part R の履歴	同じ tip で以前に Part R が fail となり、修正後に再提示された場合 → full
機微なパス／キーワード	変更されたパス ＋ タイトル／説明／コミットと reference.md「機微なパスとキーワード」を照合	glob またはキーワードに一致した場合 → full

エスカレーション条件に該当しない場合は light です（アプリケーションコードも含みます）。しきい値と機微な項目の表は、リポジトリごとに調整可能な定数です（reference.md「コンテンツに応じた深度の段階」を参照）。

3. 実行またはスキップ

1. レビューの実行が必要な場合は、frontmatter の依存関係 pr-code-review が利用可能であることを確認します（前提条件の確認は読み込み時にすでに実行済みです）。
2. 設定が never（または ask ＋ ユーザーによるスキップ）の場合は、留痕を記録して Part D に進みます（pr-code-review は読み込みません）。
3. それ以外の場合は、選択した depth（full または light）を指定して、マージ予定のオープン中の PR/MR に対して pr-code-review を読み込みます（そのスキルに従ってください — Standards∥Spec、信頼度 ≥80）。
4. 判定マトリックス：

結果	アクション
合格 — いずれの軸にも ≥80 の Critical/Important が残っていない	Part D に進む
不合格 — いずれかの軸に ≥80 の Critical/Important がある	Part D をブロックします。 ソース tip の修正だけでは解除と見なしません。次のいずれかを行います：（1）ソース tip を修正し、新しい tip で Part R を必ず再実行する（§3.5）、または（2）ユーザーが明示的にスキップ／残存リスクを受け入れたことを留痕に記録する。Part A/B の関連付けまたはリベースのルールで必要な場合に限り、Part A から再開してください。再レビューの代わりとして再開してはいけません。
スキルの適用対象外によるスキップ（クローズ済み／ドラフト／このセッションでレビュー済み）	PR が引き続きマージ候補であり、同じ tip に対する ≥80 で問題のない二軸レビューが以前に存在する場合に限り、この Part では合格として扱います。それ以外の場合はユーザーの判断を仰いでください。修正後に 以前の tip を対象として行われたクリーンなレビューは、該当するレビューとしてカウントされません。

3.5 不合格 → 修正 → クリーンになるまで再レビュー（ラウンド上限）

レビューの実行が不合格となり、エージェントがソース tip を修正した場合（明示的なスキップ／受け入れの留痕を記録した場合を除く）：

1. このマージ試行における pr-code-review の呼び出しをそれぞれ ラウンドとして数えます（最初の不合格がラウンド 1 です）。
2. 修正が tip に反映された後、深度を再判定し（§1–2.5、失敗後の再エントリーのシグナルに該当する場合は full）、Part D に進む前に新しい tip で pr-code-review を再実行します。
3. ラウンドが合格した場合（いずれの軸にも ≥80 の Critical/Important がない）、またはユーザーが明示的なスキップ／残存リスク受け入れの留痕を記録した場合に限り、Part D に進みます。
4. 上限は 3 ラウンドです。 ラウンド 3 でも不合格の場合は、一時停止してユーザーに確認します。続行（レビューをもう 1 ラウンドだけ実施し、不合格なら再び一時停止）／ブロックを維持したまま残存リスクを受け入れて留痕を記録／マージを中止、のいずれかを選んでもらいます。自動的に Part D に進んではいけません。
5. Part R を実行しなかった never／ask-skip の経路は、このループの対象外です。

留痕

ケース	テンプレート
ユーザーによる明示的なスキップ	【PR code-review 门控跳过】用户显式跳过 Part R（pr-code-review）。时间：<ISO>。决策人：用户。PR：<url or id>。
ラウンド上限後の残存リスク受け入れ	【PR code-review 残留接受】用户在 Part R 轮次封顶后接受残留 ≥80 Critical/Important。时间：<ISO>。决策人：用户。PR：<url or id>。轮次：<n>。
プロジェクト設定が never	【PR code-review 门控跳过】工程偏好 pr-review-gate: never。时间：<ISO>。决策人：项目配置。
Light 経路を使用	レビューコメントへの任意の注記：pr-review-gate: <non-code-light|auto>; surface=<non-application-code|application-code>; scale=<ok|escalated>; sensitive=<ok|hit>；depth=<light|full>

注意すべき兆候

• 「CI はグリーン」または「coverage-gate never」を理由に Part R を省略する（coverage skip は Part R の省略にはなりません）
• 分類せずに、未設定の pr-review-gate を一律の深度として扱う — 未設定 ≡ auto（内容に応じて適用：表層レビュー ＋ 規模／リスクに応じたエスカレーション）。一律の full／light／skip はすべて禁止です
• pr-code-review を読み込まずに、Claude Code の /code-review プラグインを代替として呼び出す
• Standards と Spec をひとつの優先順位付きリストにまとめ、「全体的に問題なさそう」を Part R の合格として扱う
• auto または non-code-light で application-code を常に full と扱う（full にするには、エスカレーション条件への該当、または設定 always が必要です）
• Part R の指摘を修正した後、新たに二軸のクリーンレビューを行わずに Part D に進む（明示的な skip／accept-residual の記録がある場合を除く）

---

Part D — Squash の判断 ＋ tip の固定（Part R 合格後、マージ前）

Part D は、レビュー合格からマージコマンド実行までのすべてを担います。squash の判断（Step 0）により、マージ戦略をデフォルト任せにすることを防ぎ、tip の固定（Steps 1–4）により、古い tip をマージしてしまう競合を防ぎます。（事後分析：docs/mr-merge-stale-tip-archive-miss-incident.md。）

Step 0 — Squash の判断（必須、マージコマンド実行前）

マージ戦略をデフォルト任せにすることを防ぎます。GitLab の「Merge request が承認されたときにコミットをスカッシュする」チェックボックスと GitHub の squash merge 方式は、ユーザーに提示し、確認を得る選択肢でなければなりません。プラットフォームのデフォルト設定や、AI による無言の選択にしてはいけません。選択肢の結果が分かれる場合には確認を行います。実行可能な戦略が 2 つ未満の場合は選択肢がないため、Step 0 は質問せずに結論を出します。

1. マージ予定の tip にあるコミットを一覧表示する（Step 1 で固定するものと同じ tip）：

   gh pr view <id> --json commits        # GitHub
   glab mr commits <id>                  # GitLab (or the MR commits API)
   

2. 事前チェックで判断する — いずれかに該当する場合は、結論とその理由を一行で述べ、実行に進みます（ユーザーは提示された結論を上書きできます）。

   • ベースより先行するコミットがちょうど 1 件 → 「単一コミット：no-squash」（まとめるものがありません）。
   • リポジトリ／プラットフォームのポリシーで許可されるマージ方式が 1 つだけ → その方式を採用し、適用されるポリシーを記載します。

3. 分類して推奨する（コミットが 2 件以上）— 判断表を適用し、根拠とともに推奨を述べます。

   コミット履歴	推奨
   それぞれに独立した価値があるコミット（機能／レビュー可能な改善／別々のコミットとしてのアーカイブ）	No-squash — マージコミットで履歴を保持します
   些細な変更の積み重ね（fixup／誤字修正／wip／CI 再試行のノイズなど、単独での価値がないもの）	Squash — 1 つのコミットにまとめます
   ソースブランチで今後も開発を続ける	No-squash 寄り — squash するとターゲットと共有されるコミットグラフが分断され、後続のマージで競合が起きやすくなります

4. 質問して回答を待つ — 推奨を提示し、ユーザーに明示的な選択（squash／no-squash）を求めます。実行可能な戦略が 2 つある場合に、自動で選択してはいけません。直接のマージコマンドと自動モードのホストワークフローは、いずれもここで停止します（この確認はマージフローのサブステップであり、モードを元に戻すものではありません）。ユーザーの明示的な選択が推奨に優先します。

5. 選択された戦略で実行する — 戦略は Step 1 のマージコマンド（gh pr merge <id> --merge|--squash … ／ glab mr merge <id> [--squash] …。フラグは使用する CLI のバージョンに従います）に引き継がれます。プラットフォームが squash に対応していない場合は、その制限を伝え、利用可能な方式でマージします。

ステップ 1–4 — チップのピン留め

古いチップへのマージ競合を防ぎます。マージの数秒前にプッシュされたアーカイブ／修正コミットは、マージがプッシュ前のチップ（そのパイプラインはすでに成功している）にファストフォワードされるため、ターゲットに取り込まれず、プッシュ直後のコミットはソースブランチに残ってしまいます。

1. マージリビジョンをピン留めします。

   MERGE_SHA=$(git rev-parse origin/<source-branch>)   # or the SHA returned by push
   

   ステップ 0 で選択したマージ方法を使い、glab mr merge <id> --sha "$MERGE_SHA" -y（GitLab）または gh pr merge <id> --match-head-commit "$MERGE_SHA"（GitHub。古いドキュメントでは --sha とされている場合があります。使用中の gh がサポートするフラグを使ってください）でマージします。チップをピン留めせずにマージすることは禁止です。 プラットフォームの CLI にチップをピン留めするフラグがない場合は、そのチップのパイプラインが成功するまで待ってからマージし、ステップ 3 を必須の安全策として扱ってください。

2. 即座に表示された Pipeline succeeded を信用しないでください。 マージ直前に新しいコミットがプッシュされた場合、直後に表示された Pipeline succeeded はほぼ間違いなく古いチップの結果です。結果の SHA がプッシュ直後のチップと一致することを確認するか、ステップ 1 のチップのピン留めを利用してください。

3. マージ後の祖先チェック（必須）。

   git fetch origin <target>
   git merge-base --is-ancestor "$MERGE_SHA" origin/<target> && echo OK || echo MISSING
   

   MISSING → プッシュ直後のコミット（アーカイブ／仕様同期／修正）がターゲットに取り込まれていません。完了したと主張してはならず、Jira への書き戻しにも進んではいけません。バックフィル用 MR（チェリーピック）を開くか、ユーザーの判断を待ってください。

4. 2 つの戦略とフォールバック。

   • 戦略 A（デフォルト）： MR がオープンでマージ可能であり、関連する OpenSpec 変更がすでにアーカイブ済み（または関連する変更がない）→ チップをピン留めして、同じチップ上の実装とアーカイブをマージします（ステップ 1–3 を実行）。
   • 戦略 B（復旧時のみ）： 実装 MR が誤ってすでにマージされ、アーカイブがまだ保留中 → アーカイブ用の別のドキュメント MR を開き、「archive pending !N」と明示して留痕を残します。アーカイブがすでにターゲットにあるかのように装ってはなりません。MR がまだオープンで、関連するアクティブな変更がある場合に、戦略 B を推奨してはなりません。その場合はパート A のブロック条件に該当し、戦略 B ではありません。

マージ後のワークスペース同期（祖先チェックの通過後）

マージはループの半分にすぎません。次のタスクを始める前に、ローカルワークスペースを統合ブランチに戻す必要があります。MR のベースメタデータ（gh pr view <id> --json baseRefName／GitLab の target_branch）からターゲットを特定し、すでに解決済みのベース Part B の情報を再利用してください。実際のターゲットは develop、release/*、統合ブランチであることが多いため、main や master を前提にしてはなりません。

1. ターゲットがローカルに存在する → チェックアウトしてファストフォワードします：git checkout <target> && git pull --ff-only origin <target>。同期結果を 1 行（ブランチ名と新しいチップ）で報告します。
2. ターゲットがローカルに存在しない → 取得するためのフェッチコマンドを提示します（git fetch origin <target>:<target>）。ローカルコピーがないことは報告すべき結果であり、黙ってスキップしてはなりません。
3. ファストフォワードできない（履歴が分岐している）→ 分岐を報告し、判断をユーザーに委ねます。独断でリベースや強制更新を行ってはなりません。
4. マージ済みのソースブランチを削除するよう、明示的な追加作業として提案します（ローカルとリモートの両方）。クリーンアップの責任は feature-branch-closeout にあります。

---

モードのライフサイクル

ask のもとでユーザーに尋ねたり、オプトイン後にアナライザーを実行したりしても、それだけで「自動的に手動モードに戻る」（マージフローのサブステップ）が発生するわけではありません。ゲートによる一時停止（パート A のブロック／閾値未満／クラッシュ／should-run の暗黙的な未検出／ask の回答待ち／パート R の失敗）によってマージフローが中断された場合は、既存のルールに従って手動モードに戻ります。パート B のリベース実行にも同じルールが適用されます。ユーザーが確認したリベースはマージフローのサブステップであり、それ自体では手動モードに戻りません。未解決の競合または中止されたリベースはマージフローを中断し、手動モードに戻ります。

ワークフローを参照するための統合ガイド

• 独自の本文に含める内容： ステージの順序を示す行（例：archive → branch-closeout → merge-discipline(A→B→C→R→D) → merge → writeback）、このスキルへの簡潔な参照、重要なレッドフラグを1～2件含めます。Part の手順を本文にコピーしないでください。
• このスキルに委任する内容： 5つすべての Part — A（アーカイブゲート）、B（リベース）、C（カバレッジ）、R（pr-code-review によるPRコードレビュー）、D（チップのピン留め）。
• マージ前チェックリスト（唯一の参照元）： reference.md「マージ前チェックリスト」／「Pre-merge checklist」。これを参照するワークフローでは、参照文を1つだけ記載します。チェックリストをワークフローの reference.md に貼り付けないでください。
• 強力な依存関係が不足している場合： 中止し、スキルごとに npx skills add FuDesign2008/open-skills -g --skill <name> --yes を出力します（Prerequisite skill check を参照）。