---
title: merge-issue
description: マージ前の事前確認(プリフライトチェック)と、完了後に自動で進む更新処理(ロールアップ)の連鎖
seo:
  image: /ogp.png
---

**プリフライトチェック(マージする前に行う一連の事前確認)が全て合格しない限り、マージは実行されません。**
これがこのスキルの特徴です。

- PR/MRがopen状態(既にマージ/クローズされていない)
- 最新レビューラウンドの判定がMergeable(ブロッカー0件)
- 必須承認が存在する
- CI/パイプラインがgreen(設定されていれば)
- コンフリクトなし、ベースブランチと同期済み

## コマンドと主なオプション

```
/architect:merge-issue [item|mr|pr] [--strategy=merge|squash|rebase] [--delete-branch] [--yes-merge] [--dry-run] [--auto] [--lang=en|ja]
```

| オプション | 意味 |
|---|---|
| `item\|mr\|pr` | 対象。Issue(`I1.2.3`・`#<iid>`・URL)でも、PR/MRを直接指定してもよい。省略時はmanifestから解決する |
| `--strategy` | マージ方法。`merge`(そのまま)・`squash`(1コミットにまとめる)・`rebase`。省略時はプロジェクトの既定値 |
| `--delete-branch` | マージ後に作業ブランチを削除する |
| `--yes-merge` | 確認ゲートを事前承認扱いにしてスキップする。**このゲートを飛ばせる唯一の手段** |
| `--dry-run` | 何もマージせず、何がマージされるかだけ報告する |
| `--auto` | 途中の確認を省略する。ただしマージの確認ゲートはスキップされない |
| `--lang` | コメントやレポートの出力言語 |

:::danger[確認ゲートは--autoではスキップされない]
確認ゲート(マージの直前に必ず入る確認のタイミング)は、`--yes-merge`を指定したときだけスキップできます。
`--auto`を指定していても、このゲートはスキップされません。マージは、一度実行すると元に戻せない、
外部への影響が大きい操作だからです。
:::

## ロールアップの連鎖

マージが成功すると、次の一連の更新(ロールアップ)が自動で起きます。

```mermaid
flowchart TD
  A["マージ成功"] --> B["Issueをクローズ + status::done<br/>Delivery StatusのMergedをチェック"]
  B --> C["Sub-Epicの子タスクリストを検証<br/>(漏れていればチェック)"]
  C --> D{"Sub-Epic内の全Issueが完了?"}
  D -- はい --> E["Sub-Epic: status::done"]
  D -- いいえ --> G["backlog-manifest.jsonを更新"]
  E --> F["Epicの子タスクリストを検証"]
  E --> R["ロールアップレビュー起動(merge-issueのみ)"]
  F --> G
```

1. **Issueをクローズ + status::done**

    対象のIssueが完了扱いになります。あわせて`## Delivery Status`の`Merged`にチェックが入ります。
    確認ゲートでユーザーが「未達のままマージする」と判断した受入基準は、チェックなしのまま
    マージコメントに明記されます。

2. **Sub-Epicの子タスクリストを検証**

    `## Issues`タスクリストの該当Issueのチェックは、本来`implement-backlog`が実装完了時に入れています。
    このスキルは**入っているかを確認するだけ**で、漏れていた場合だけチェックを入れます
    (マージされてCIがgreenなら、実装が終わっている証拠になるため)。
    すべてのIssueが完了したら、Sub-Epic自体も`status::done`になります。

3. **Epicの子タスクリストを検証**

    Sub-Epicが`done`になったときだけ、`## Sub-Epics`タスクリストの該当チェックを同じように検証します。

4. **backlog-manifest.jsonを更新**

    このロールアップで動いた**すべてのノード**の`impl.status`を更新します。Issueだけでなく、
    `done`になったSub-Epic/Epicも対象です。親の完了をトラッカー側にしか書かないと、あとで
    `deliver-backlog`が再開したときに、完了済みのSub-Epicを未着手と誤読してしまいます。

:::note[ロールアップレビューを起動できるのはmerge-issueだけ]
Sub-Epicが完了したときは、**Epic全体を見直すロールアップレビューが起動するべき**という設計になっています。
ただし、この起動を行える権限を持つのは`merge-issue`だけです。`implement-backlog`の側から自分で起動する
ことはありません。
:::