> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Post-Merge Actions

> Run automated follow-up work, including changelog updates, tickets, and notifications, after a pull request is merged.

export const ProPlusPlanBadge = ({tip = "This feature is available as part of the Pro+ plan and Enterprise plan. Please refer to our pricing page for more information about our plans and features.", title = "Pro+ Plan", cta = "Read more", href = "https://coderabbit.ai/pricing", disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="shield-plus" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

export const AllPlatformsBadge = ({tip = "This feature is available on all supported platforms: GitHub, GitLab, Azure DevOps, and Bitbucket.", title = "All Platforms", cta, href, disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="globe" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

<AllPlatformsBadge /> | <ProPlusPlanBadge />

Post-Merge Actions run automated follow-up work after a pull request is merged. Each action is a natural-language instruction that CodeRabbit executes agentically against the merged changes. It can open a follow-up pull request, post a report on the PR, or deliver output to a connected integration. Administrators configure actions at the organization or repository level. Post-Merge Actions are the merge-time counterpart to [Pre-Merge Checks](/pr-reviews/pre-merge-checks): pre-merge checks gate a PR *before* it lands, while post-merge actions do work *after* it lands.

## Why use Post-Merge Actions?

* **Automate the busywork after merge:** Append changelog entries, bump docs, or open cleanup PRs without a human remembering to.
* **Close the loop with your tools:** File a Linear or Jira ticket, open a GitHub issue, or post a Slack summary the moment work lands.
* **Keep authors in control:** Every action is previewed as a checkbox in the PR walkthrough before merge, so authors and reviewers can skip actions that do not fit.
* **Scoped to what merged:** Actions receive the merged diff, PR summary, and objectives, so their instructions can target exactly the changes that landed.

## How Post-Merge Actions work

<Steps>
  <Step title="Preview during review">
    While CodeRabbit reviews an open PR, each enabled action appears as a checkbox in the **🚀 Post-Merge Actions** section of the walkthrough. A box is checked only when CodeRabbit determines that the action applies to this PR's changes. If it cannot determine applicability, the box remains unchecked.
  </Step>

  <Step title="Skip actions (optional)">
    The PR author or a reviewer can skip actions they do not want with a [skip command](#skipping-actions) before merging.
  </Step>

  <Step title="Run on merge">
    When the PR is merged into the default branch, CodeRabbit runs every action whose box is still checked. Each action executes agentically in a secure sandbox clone of the repository with access to the merged diff and PR context.
  </Step>

  <Step title="Report results">
    CodeRabbit posts a single result comment on the merged PR summarizing each action's outcome. If any action fails, the PR author is @mentioned so the failure surfaces to them.
  </Step>
</Steps>

<Info>
  Actions run only when a PR is merged into the repository's **default branch**. Merges into other branches do not trigger post-merge actions.
</Info>

## Output modes

Each action picks the output mode that fits its instructions:

<CardGroup cols={3}>
  <Card title="Code changes" icon="code-xml">
    The agent edits or creates files, such as appending to a changelog. The changes are opened as a **follow-up pull request** against the default branch.
  </Card>

  <Card title="Text report" icon="file-text">
    The agent produces a free-form report or summary, surfaced inline in the result comment on the merged PR.
  </Card>

  <Card title="Integration" icon="plug">
    The agent delivers output through a connected [MCP tool](/integrations/mcp-servers), for example by creating a Linear or Jira ticket, opening a GitHub issue, or posting to Slack.
  </Card>
</CardGroup>

Follow-up pull requests opened by a code-changes action are titled with a `🔧 CodeRabbit Post-Merge Recipe:` prefix. Merging one of these follow-up PRs never triggers another round of post-merge actions, so actions cannot recurse.

## Configuration

Post-Merge Actions can be configured via the web interface or the `.coderabbit.yaml` file. Each action has:

* **Enabled:** Whether the action runs after merge. The default is `true`.
* **Name:** A display name, unique among configured actions without regard to case, up to 100 characters.
* **Prompt:** Deterministic natural-language instructions describing the action to perform, up to 10,000 characters.

You can configure up to **5** post-merge actions.

<Info>
  To create tickets, post Slack messages, or use other integrations, first configure and enable the relevant [MCP server](/integrations/mcp-servers).
</Info>

<Tabs>
  <Tab title="Web interface" icon="browser">
    Configure Post-Merge Actions through the CodeRabbit dashboard:

    <Steps>
      <Step title="Navigate to Settings">
        In CodeRabbit, open **Settings** and configure actions at the organization or repository level.
      </Step>

      <Step title="Add an action">
        Add an action with:

        * **Name** (≤ 100 chars, unique within the org)
        * **Prompt** (≤ 10,000 chars; natural language)
        * **Enabled** (on | off)
      </Step>

      <Step title="Apply changes">
        Click **Apply Changes** to save. The new actions apply to subsequent reviews and merges.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Configuration file" icon="file-code">
    For version-controlled configuration, add actions to your `.coderabbit.yaml` file:

    ```yaml YAML icon=code wrap theme={null}
    reviews:
      post_merge_actions:
        - name: "Update changelog"
          enabled: true
          prompt: "If this PR contains user-facing changes, append a concise entry to CHANGELOG.md under the Unreleased section describing the change. Skip purely internal refactors, tests, and CI changes."
        - name: "File follow-up ticket"
          enabled: true
          prompt: "If this PR references a known TODO or leaves follow-up work described in the PR description, create a Linear ticket summarizing the follow-up and link back to this PR."
        - name: "Notify release channel"
          enabled: false
          prompt: "Post a one-paragraph summary of the merged changes to the #releases Slack channel."
    ```
  </Tab>
</Tabs>

The prompt can include filter conditions, such as labels, changed paths, or branch names. During review, CodeRabbit evaluates each enabled action against the pull request. Actions that do not apply, or whose applicability cannot be determined, remain unchecked and do not run after merge.

## Skipping actions

The PR author or a reviewer can opt out of actions before merging with a chat command.

### Skip all actions

```md theme={null}
@coderabbitai skip post-merge actions
```

### Skip specific actions

Pass one or more `--name` flags to skip only those actions (names are matched exactly, casing preserved):

```md theme={null}
@coderabbitai skip post-merge actions --name "Update changelog" --name "Notify release channel"
```

The skip command clears the selected action's checkbox in the **🚀 Post-Merge Actions** section. Only actions whose boxes are still checked at merge time run.

<Info>
  Skipping applies only to that PR. Future PRs still evaluate and offer actions as configured.
</Info>

## Results comment

After a merged PR's actions run, CodeRabbit posts a single **🚀 Post-Merge Actions** result comment listing each action and its outcome:

* ✅ **Success:** A detail line includes a link to the follow-up PR, the text report, or a note that output was delivered through a connected integration.
* ❌ **Failure:** A short reason is included. When any action fails, the PR author is @mentioned at the top of the comment.

Re-triggering post-merge actions after they run is not supported; the result comment is a record of the single run.

> See [**Manage code reviews**](/guides/commands) for more commands and behaviors.

## Examples

<Tabs>
  <Tab title="Changelog entry">
    Appends a changelog entry once the change is final. Running this post-merge avoids documenting in-progress work that may still change before the PR closes.

    ```yaml theme={null}
    reviews:
      post_merge_actions:
        - name: "Update changelog"
          enabled: true
          prompt: |
            Review the PR title, description, and full diff.
            Append a new entry to CHANGELOG.md at the top of the "Unreleased" section.

            Format: `- <type>(<scope>): <short description> (#<PR number>)`
            - Derive type from the changes: feat, fix, refactor, docs, chore
            - Derive scope from the primary directory or package touched
            - Keep the description under 80 characters in plain language

            Only proceed if the PR is a notable user-facing or API change.
            Skip for dependency bumps, typo fixes, and CI-only changes.
            Do not modify anything else in the file.
    ```
  </Tab>

  <Tab title="Update Notion page">
    <Info>
      Enable the [Notion MCP server](/integrations/mcp-servers) first.
    </Info>

    Posts a plain-language ship summary to a Notion page when a PR merges. Post-merge is the natural trigger — "this shipped" is a merge-time signal.

    ```yaml theme={null}
        - name: "Notify on ship"
          enabled: true
          prompt: |
            Read the PR title, description, and CodeRabbit summary.
            Write a 2-3 sentence plain-language summary of what this PR ships and why it matters.

            Use the Notion MCP tool to append the summary as a new row or block to the
            team's "What shipped this week" page. Include the PR URL and today's date.
    ```
  </Tab>

  <Tab title="Sync docs">
    Updates documentation to match the merged code. Post-merge timing ensures docs reflect the final implementation, not a draft.

    ```yaml theme={null}
        - name: "Sync docs"
          enabled: true
          prompt: |
            Check the diff for changes to any public API, configuration option, CLI flag,
            or user-facing behavior.

            For each change found, update the corresponding section in the docs/ directory:
            - API changes → docs/api-reference/
            - Config changes → docs/configuration.md
            - CLI changes → docs/cli.md

            If a relevant doc file does not exist, create a stub with the correct heading
            and a one-paragraph description derived from the code and PR description.

            Do not update docs for internal refactors, test changes, or CI changes.
    ```
  </Tab>

  <Tab title="Update Linear">
    <Info>
      Enable the [Linear MCP server](/integrations/mcp-servers) first.
    </Info>

    Closes the linked Linear issue and logs what shipped when the PR merges. Eliminates the manual step of updating ticket status after a merge.

    ```yaml theme={null}
        - name: "Update Linear ticket on merge"
          enabled: true
          prompt: |
            Extract the Linear ticket ID from the PR title or branch name.
            Common patterns: ABC-123, ENG-456, PROJ-789.

            If a ticket ID is found:
            1. Use the Linear MCP tool to update the issue status to "Done".
            2. Add a comment to the issue with:
               - One sentence summarizing what was shipped, derived from the PR description
                 and CodeRabbit summary
               - The PR URL
               - Today's date

            If no ticket ID is found, do nothing.
    ```
  </Tab>

  <Tab title="Create tickets">
    <Info>
      Enable the [Linear MCP server](/integrations/mcp-servers) first.
    </Info>

    Any CodeRabbit comment left unresolved at merge time becomes a tracked Linear issue, so review findings don't get lost. Only possible post-merge when the final unresolved state is known.

    ```yaml theme={null}
        - name: "Track unresolved review comments"
          enabled: true
          prompt: |
            Read all CodeRabbit inline review comments on this PR.
            Identify comments that were left unresolved at the time of merge —
            these are comments where the suggestion was not applied and the thread
            was not marked resolved.

            For each unresolved comment, use the Linear MCP tool to create a new issue with:
            - Title: a concise summary of the finding (under 80 characters)
            - Description: the full comment text, the file path and line number it refers to,
              and the PR URL for context
            - Priority: use the comment's severity as a signal — bugs or security findings
              are High, style or improvement suggestions are Medium
            - Label: "tech-debt" or "code-review-followup" if those labels exist in the workspace

            Do not create tickets for comments that were resolved or for nitpicks
            explicitly marked as non-blocking.
    ```
  </Tab>
</Tabs>

## What's next

<CardGroup cols={1}>
  <Card title="Pre-Merge Checks" href="/pr-reviews/pre-merge-checks" icon="shield-check" horizontal>
    Enforce quality gates and custom requirements before pull requests merge, the merge-time counterpart to post-merge actions.
  </Card>

  <Card title="MCP servers" href="/integrations/mcp-servers" icon="plug" horizontal>
    Connect the tools that integration actions use to file Linear or Jira tickets, open GitHub issues, or post to Slack.
  </Card>

  <Card title="PR Walkthroughs" href="/pr-reviews/walkthroughs" icon="list-tree" horizontal>
    See how the walkthrough comment surfaces each action as a checkbox before merge.
  </Card>
</CardGroup>