---
title: merge-issue
description: >-
  Preflight checks before merging and the automatic rollup chain that runs after
  a successful merge
seo:
  image: /ogp.png
---
**A merge will not execute unless all preflight checks pass.**
That is the defining characteristic of this skill.

- The PR/MR is open (not already merged or closed)
- The verdict for the latest review round is Mergeable (0 blockers)
- Required approvals exist
- CI/pipeline is green (if configured)
- No conflicts; in sync with the base branch

## Command and Key Options

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

| Option | Meaning |
|---|---|
| `item\|mr\|pr` | Target. Can be an Issue (`I1.2.3`, `#<iid>`, or URL) or a PR/MR specified directly. If omitted, resolved from the manifest. |
| `--strategy` | Merge method: `merge` (as-is), `squash` (collapsed into one commit), or `rebase`. Defaults to the project's configured default. |
| `--delete-branch` | Delete the working branch after merge. |
| `--yes-merge` | Pre-approves the confirmation gate and skips it. **The only way to bypass this gate.** |
| `--dry-run` | Reports what would be merged without actually merging anything. |
| `--auto` | Skips intermediate confirmations. Does not skip the merge confirmation gate. |
| `--lang` | Output language for comments and reports. |

:::danger[--auto does not skip the confirmation gate]
The confirmation gate (the mandatory confirmation step immediately before a merge) can only be skipped by passing `--yes-merge`.
Even with `--auto` specified, this gate is not skipped. A merge is an irreversible operation
with significant external impact.
:::

## Rollup Chain

When a merge succeeds, the following sequence of updates (rollup) runs automatically.

```mermaid
flowchart TD
  A["Merge succeeded"] --> B["Close Issue + status::done<br/>Check Merged in Delivery Status"]
  B --> C["Validate child task list of Sub-Epic<br/>(check if missing)"]
  C --> D{"All Issues in Sub-Epic complete?"}
  D -- Yes --> E["Sub-Epic: status::done"]
  D -- No --> G["Update backlog-manifest.json"]
  E --> F["Validate child task list of Epic"]
  E --> R["Launch rollup review (merge-issue only)"]
  F --> G
```

1. **Close Issue + status::done**

    The target Issue is marked as complete. The `Merged` checkbox in `## Delivery Status` is also checked.
    Any acceptance criteria that the user decided to merge without meeting at the confirmation gate
    are left unchecked and explicitly noted in the merge comment.

2. **Validate the Sub-Epic's child task list**

    The check for the relevant Issue in the `## Issues` task list is normally set by `implement-backlog` when implementation completes.
    This skill **only verifies that the check is present** and adds it only when it is missing
    (a merged PR with a green CI serves as proof that implementation is done).
    When all Issues are complete, the Sub-Epic itself transitions to `status::done`.

3. **Validate the Epic's child task list**

    Only when a Sub-Epic becomes `done` is the corresponding checkbox in the `## Sub-Epics` task list validated in the same way.

4. **Update backlog-manifest.json**

    Updates the `impl.status` of **every node** that moved during this rollup. This includes not just the Issue but also any Sub-Epic or Epic that became `done`. Writing parent completion only on the tracker side causes `deliver-backlog`, when it resumes later, to misread a completed Sub-Epic as not yet started.

:::note[Only merge-issue can launch a rollup review]
The design specifies that **a rollup review covering the entire Epic should be launched** when a Sub-Epic completes.
However, only `merge-issue` has the authority to trigger that launch. The `implement-backlog` side never launches it on its own.
:::