Skip to main content
Tame the sprawling PR backlog. This scheduled automation surfaces pull requests that have gone quiet — no comments, no commits, no movement — and takes action: a friendly ping to the author, a rebase if the branch has fallen behind, or a graceful close if the PR has been abandoned for weeks.

Use this template

Open Stale PR Cleanup in Devin and create the automation with the default configuration. You can customize it before saving.

​
What this automation does

Stale PRs are a tax on team velocity. Reviewers skip them, authors forget about them, and conflicts accumulate until merging is a mini-project. This template runs weekly, identifies PRs that have been idle beyond a threshold you configure, and takes context-aware cleanup actions: ping, rebase, or close.

​
How it works

Trigger: Schedule event — recurring
  • Event: schedule:recurring
    • Conditions:
      • rrule matches FREQ=WEEKLY;BYDAY=WE;BYHOUR=10;BYMINUTE=0
What Devin does: Starts a session with full event context, executes the prompt below, and (optionally) notifies you on failure.

​
Prerequisites

​
Example prompt

The template ships with this prompt. You can edit it after clicking Use template, or leave it as-is.

​
Setting it up

  1. Open Automations → Templates in Devin.
  2. Click Stale PR Cleanup. The create page opens with this template pre-filled.
  3. Connect any required integrations and install MCP servers if you haven’t already.
  4. Replace any placeholder values in the trigger conditions (for example, swap your-org/your-repo for your actual repo).
  5. Review the prompt and adjust it for your team’s language, conventions, and guardrails.
  6. Click Create automation.
Most automation templates include suggested ACU and invocation limits to bound cost during early rollout. Keep them as-is until you’re confident in the automation’s behavior, then raise them to fit your workload.

​
When to use this template

  • Engineering teams with large open-source contribution flows
  • Internal repos with long PR backlogs and heavy review bottlenecks
  • Keeping main branches free of merge conflicts from forgotten branches
  • Reducing cognitive load on reviewers scrolling through the PR list

​
Customization ideas

  • Tune the stale threshold (7 days, 30 days, 90 days)
  • Scope to specific repos or labels
  • Add a grace-period warning comment before any destructive action
  • Integrate with Slack so authors get a DM, not just a GitHub notification

​
See also