# Close the loop after every merge: the agent that reviewed your PR can now follow through > Source: > Published: 2026-07-16 00:00:00+00:00 Sahana Vijaya Prasad July 16, 2026 4 min read July 16, 2026 4 min read Cut code review time & bugs by 50% Most installed AI app on GitHub and GitLab Free 14-day trial After a pull request merges, a team may still need to write the changelog entry, update the right documentation section, or create a follow-up ticket for work that did not belong in the original change. By then, the context behind the decision can be harder to reconstruct. Some follow-through is mechanical: a linked ticket can close, a version can bump, or a notification can send. Other work depends on understanding what the pull request changed and whether that change is worth documenting, communicating, or tracking. [Post-Merge Actions](https://docs.coderabbit.ai/pr-reviews/post-merge-actions) give the CodeRabbit agent that context. They run after a pull request is merged to the default branch and can carry the change through the work that follows. Post-Merge Actions are custom automations that CodeRabbit evaluates during the pull-request review. Before merge, every enabled action appears in the CodeRabbit walkthrough as a checkbox. Applicable actions are checked; actions that do not apply, or whose applicability is unclear, remain unchecked. Authors and reviewers can also opt out of an action before merging. After the pull request merges, CodeRabbit runs the checked actions and posts a single result comment on that merged pull request. The comment records each action's outcome and includes details about any follow-up output. Post-Merge Actions are the merge-time counterpart to [Pre-Merge Checks](https://www.coderabbit.ai/blog/pre-merge-checks-built-in-and-custom-pr-enforced). Pre-Merge Checks evaluate requirements before a change lands; Post-Merge Actions use the same pull-request context for follow-through after it merges. Admins can configure actions at the organization or repository level. Each action uses a prompt to decide whether it applies and what it should do. Its output can take one of three forms: `CHANGELOG.md` after a user-facing change.Follow-up pull requests created by code-change actions do not start another round of Post-Merge Actions when they merge. That keeps the workflow reviewable and prevents accidental recursion. The workflow starts where engineering work already happens. CodeRabbit reviews the pull request, then surfaces the actions that are relevant to that specific change in the walkthrough. A documentation action might be checked for a new public feature, but remain unchecked for an internal refactor. A release notification might be checked only when files in a product area changed. That decision happens before merge, when the author and reviewers can still see the complete context. They can keep an action selected, clear it, or skip a specific action with a chat command. The result is a deliberate handoff from review to follow-through, rather than a background job that runs on every merged pull request. You can configure Post-Merge Actions in CodeRabbit settings at the organization or repository level, or version them in `.coderabbit.yaml` . Each action has a name, an enabled state, and a natural-language prompt. The prompt is the operating policy. It should say what to inspect, what to change or create, and when to do nothing. Specific instructions make actions more useful and less noisy. ``` 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. Skip internal refactors, tests, and CI-only changes." ``` For a ticketing action, name the conditions that count as unfinished work. For a documentation action, name the exact files to inspect and the sections that may need updating. Add a clear no-op condition so the agent does not force a follow-up when the change does not need one. The full configuration reference covers YAML and dashboard setup, action limits, and the commands reviewers can use to skip actions for a pull request. Post-Merge Actions can use connected MCP servers when the result belongs beyond the repository. For example, an action can create a Linear or Jira ticket for a documented follow-up, open a GitHub issue, or post a release notification to Slack. The relevant server must be configured and its required tools enabled in CodeRabbit first. [MCP integrations](https://docs.coderabbit.ai/integrations/mcp-servers) also let you give CodeRabbit guidance on what each connected system contains and how the agent should use it. That extra context matters when a project tracker or knowledge base contains much more than the information an action needs. Post-Merge Actions are most useful when the right next step depends on the change itself: For a mechanical trigger that does not need pull-request context, consider using your existing CI or webhook automation. Use Post-Merge Actions for the follow-through that depends on the review context the team would otherwise lose after merge. Post-Merge Actions are included in [CodeRabbit Pro+ and Enterprise plans](https://docs.coderabbit.ai/management/plans).