Skip to main content
As coding agents become more prevalent, the bottleneck shifts from writing code to reviewing it. Devin Review is a full-service code review platform within the Devin webapp that turns large, complex PRs into intuitively organized diffs and precise explanations. It supports GitHub (including GitHub Enterprise Server and Enterprise Cloud), GitLab (including Self-Managed GitLab), and connected Azure DevOps, Bitbucket Data Center, and Bitbucket Cloud repositories. Perforce Swarm reviews are also supported for accounts with Perforce connections enabled.

Devin Review in action

Devin Review is available for PRs on GitHub repositories (including GitHub Enterprise Server and Enterprise Cloud) and merge requests on GitLab repositories (including Self-Managed GitLab). Connected Azure DevOps, Bitbucket Data Center, and Bitbucket Cloud repositories support diffs, analysis, comments, and auto-review; see Supported Git Providers for available actions. Public PRs don’t require a Devin account. Private PRs can be viewed with a Devin account.

​
Features

Beta features: Custom reviewers, Autoapprover, and review-context instructions are beta features. Availability varies by account, and their behavior and settings may change. If a feature is missing, contact your Cognition representative to ask about access.

Smart diff organization

Groups changes logically, putting related edits together instead of alphabetical order.

Copy and move detection

Detects when code has been copied or moved and displays changes cleanly, instead of full deletes and inserts.

Bug catcher

Checks for bugs and labels them by confidence level. Severe bugs require immediate attention.

Security scanning

Detects security vulnerabilities and suggests hardening improvements, with CWE classification and severity levels.

GitHub compatibility

Leave comments, approve PRs, request changes—all within Devin Review, synced to GitHub.

Codebase-aware chat

Ask questions about the PR and get answers with relevant context from the rest of the codebase. You can also ask Devin directly from any comment, bug, or flag in the diff view.

PR workflow actions

Merge, close, convert to draft, mark ready for review, and toggle auto-merge directly from Devin Review without leaving the page.

Code changes from chat

Ask the chat agent to make code edits. Review the suggested changes, then apply them as a commit to the PR branch without leaving Devin Review.

​
Getting Started

  • Devin webapp — Head to app.devin.ai/review to see your open PRs organized by category (assigned to you, authored by you, review requested). When Devin makes PRs, you’ll see an orange “Review” button in the chat.
  • PR comment — Comment /devin review on any GitHub PR in a repository your organization has connected, and Devin reviews it on the spot. See Triggering a Review from a PR Comment.
  • URL shortcut — For any GitHub.com PR link, replace github.com with devinreview.com in the URL. For private PRs, sign in to Devin first.
  • GitHub Enterprise — Paste the full PR URL into the Devin Review page at app.devin.ai/review. All GitHub offerings (GitHub.com, Enterprise Server, Enterprise Cloud) have the same capabilities.
  • Azure DevOps — Paste the full PR URL (for example https://dev.azure.com/.../pullrequest/..., or your Azure DevOps Server host) into app.devin.ai/review after connecting the repository to Devin.

​
Supported Git Providers

GitHub includes GitHub.com, GitHub Enterprise Server, and GitHub Enterprise Cloud — all have the same capabilities. Write features (comments, reviews, merge actions, code changes from chat) require a GitHub App connection installed on your GitHub organization. PAT-based connections are read-only and cannot post comments, submit reviews, or perform merge actions. To set up the GitHub App, see the GitHub integration guide. GitLab includes GitLab.com and Self-Managed GitLab. Connect the repository to Devin and link your personal GitLab account for user-attributed comments, reviews, and supported workflow actions. See the GitLab Self-Managed integration guide for connection setup. Azure DevOps includes Azure DevOps Services (dev.azure.com) and Azure DevOps Server 2020/2022. Connect through the Azure DevOps integration, a Microsoft Entra service principal, or an Azure DevOps Server collection with a personal access token, then enroll repositories from Settings > Review for auto-review. Devin posts automated findings through the connected service identity. To comment, reply, resolve threads, vote on a PR, or abandon a PR as yourself, link your personal Azure DevOps account to Devin. User-attributed actions require a supported delegated Microsoft identity; a shared server PAT does not supply one. Chat edits can be applied as a single commit, and linked accounts can list their PRs in Review. Merging, draft actions, and auto-merge are not available. Bitbucket Data Center requires version 8.16 or later, connected through the Bitbucket integration. To comment, add or remove reviewers, approve, or decline a PR from Devin Review, link your Bitbucket account. Merging, labels, assignees, and reactions are not available, and code changes from chat are committed one file at a time. Bitbucket Cloud (bitbucket.org) is supported through the Bitbucket integration. Connect your workspace with an access token or a dedicated Devin account linked with OAuth that administers the repositories (Devin installs the webhooks auto-review needs itself), then add automatic review rules from Settings > Review. Comments, replies, and declining a PR from Devin Review are posted as you, using your own Bitbucket account. Requesting reviewers, merging, draft actions, auto-merge, labels, assignees, and reactions are not available. Code changes from chat are committed in a single commit. Perforce Swarm supports review analysis and automated findings through the connection’s service identity. The Devin Review UI is read-only for human comments and approval actions on this provider, and it cannot apply chat edits as commits. Swarm reviews do not appear in the personal PR inbox. Perforce connections are available to selected accounts.

​
Reading a Review

The analysis starts with a short overview of the PR’s behavior and impact, followed by key changes in bullets when useful. Related edits are grouped into sections with explanations alongside their diffs. On mobile, the review opens on Changes. Switch to Bugs to see bugs, flags, and security findings, or use Description, Discussion, and Commits for the PR’s other details. When a link to a GitHub comment or review opens in Devin Review, it scrolls to and highlights the target. This also works in the review tab inside a Devin session.
  • Mark files Viewed to track your progress, or mark all files viewed or unviewed from the file list.
  • Expand context lines around a change, open the full file, or switch a Markdown file between its rendered diff and source.
  • Hide whitespace-only changes to focus on substantive edits.
  • Use Review history to inspect an earlier analysis. A link pinned to an older commit does not automatically show the newest results; use Switch to latest or Run analysis on latest when available.
  • Check the Checks view for CI status. On providers that support it, manage reviewers, labels, and assignees without leaving Review.
The available tabs and controls depend on the provider and the Review layout enabled for your account.

​
Permissions

Devin Review access is controlled by Devin Review permissions in the role editor. Usage tiers distinguish manual review, review on PR creation, and full automatic review. Configuration requires Manage Review (shown as Manage Devin Review in some role editors). Enterprise admins can use Custom Roles to restrict usage or grant configuration access. Account-level permissions govern account-wide configuration; organization-level Review permissions govern access within enterprise organizations. The scopes you can edit also depend on repository access and enterprise settings. Self-enrollment, where enabled, does not require Manage Review, but the available trigger modes are limited by your usage tier. See Account-level roles for the full list of Devin Review permission tiers and what each one grants.
Enterprise accounts: Organization Review managers can configure permitted scopes without being primary-organization admins. Account-wide controls, such as posting defaults and review-context instructions, still require account-level Manage Review. Enterprise policy can prevent organization-level edits.

​
Governance

Enterprise admins can control who uses Devin Review, what level of automation they have, and how much it costs — all from the Devin webapp.
Enterprise organization and consumption controls require a Devin Enterprise account. Per-PR automatic review spending limits also apply to quota-based plans. For enterprise plans, contact sales.

​
Cost control

Devin Review consumes ACUs (Agent Compute Units) from your enterprise’s ACU pool, the same pool used by Devin sessions and other Devin products. Enterprise admins have several tools to monitor and control review costs.

​
Consumption dashboard

The enterprise consumption dashboard at Settings > Consumption breaks down ACU usage by product, including a dedicated Review line in the daily consumption chart. Organization admins can view their org’s review consumption from Settings > Consumption Analytics. The dashboard includes:
  • Per-user breakdown — See how many review ACUs each user consumed in the current and previous billing cycle.
  • Per-repository breakdown — See review ACU consumption, review count, and the number of bugs caught by repository for the current and previous billing cycle, helping identify which repos drive the most review cost and where reviews catch the most issues.
Devin Review usage counts toward its billing organization’s ACU limit. New review work is blocked when that organization reaches its limit.

​
Review size indicator

Each PR in Devin Review displays a consumption pill showing the review’s t-shirt size based on total ACU usage across all review jobs on that PR: Hover over the size pill to see the exact ACU total, the number of review jobs run, and the cost of the currently viewed review. This helps reviewers understand the cost impact of re-running reviews or enabling auto-review on high-churn PRs.

​
Per-PR auto-review spend limit

Admins can cap how much Devin Review spends on automatic reviews of a single PR from Settings > Review under Auto-review limits (on the Billing tab in the updated layout). The limit is measured in ACUs on ACU-based plans, or in dollars of on-demand spend on quota-based plans. Leaving the field empty uses the Cognition-managed default shown in settings; it does not mean unlimited. Once a PR’s total review spend across all of its review jobs reaches the limit, auto-review is turned off for that PR and future auto-reviews are skipped. Reaching the limit is a soft block:
  • Manual reviews still work — the limit only pauses automatic reviews. You can always trigger a review yourself from the PR review page.
  • Re-enable per PR — Turning auto-review back on from the PR’s actions menu resumes reviews and adds another budget allowance. Recorded spend is not reset, and automatic reviews can pause again when the new budget is exhausted.
The consumption display shows review usage and limit status. If PR description updates are enabled, the Devin Review status row in the PR description also notes when auto-review was paused by the spend limit, with a link to re-enable it.

​
Review Effort and Billing Organization

Review effort in Review settings lets an account Review manager choose the default Normal or Ultra effort. Normal prioritizes price-performance; Ultra performs a more thorough review at a higher cost. Enterprise accounts also have a Default billing organization setting for reviews whose billing organization cannot otherwise be resolved. It requires account-settings permission. Where organization attribution is enabled, the review consumption display can show which organization, or the account itself, was billed for the most recent review.

​
PR Workflow Actions

Devin Review lets you take action on PRs directly from the review page, without switching to GitHub.
  • Merge — Merge the PR using the repository’s configured merge strategy (merge commit, squash, or rebase). The merge button reflects the PR’s current mergeability status and required checks.
  • Close — Close the PR without merging. Available from the dropdown menu next to the merge button.
  • Convert to draft — Convert an open PR to draft status. Available from the dropdown menu when the PR is open and not already a draft.
  • Mark ready for review — Mark a draft PR as ready for review. A “Ready for review” button appears in the merge bar for draft PRs.
  • Auto-merge — Enable or disable GitHub auto-merge from the merge button dropdown. When enabled, the PR will merge automatically once all required checks pass. The merge bar shows the current auto-merge status, including who enabled it.
The actions above describe GitHub, where they require a GitHub App connection and your linked GitHub identity. Actions are disabled in read-only mode. Other providers support only the subset listed under Supported Git Providers.

​
Stacked PRs

Devin Review treats stacked PRs as first-class. When a PR belongs to a stack, the review page shows the whole series and handles merging correctly:
  • Stack panel — The PR header shows the stack with every member ordered bottom-to-top, down to the base branch it merges into. Each member links to its own review page, so you can read the stack layer by layer.
  • Per-layer readiness — Each member shows a status dot reflecting its true mergeability: green when it can actually merge (accounting for CI, required reviews, and branch protection), red for failing checks or conflicts, and orange for anything else blocking the merge — including when a layer is individually ready but blocked by an unmergeable PR below it. An aggregate indicator summarizes the whole stack.
  • Focused diffs — Each PR in a stack is diffed against the layer below it, so every review — including auto-review and the bug catcher — sees only that layer’s change.
  • Stack merge — Stacked PRs merge through GitHub’s atomic stack merge: merging a PR also merges every open PR below it in the stack, bottom-up, in a single operation. The merge button shows exactly how many PRs the action will land, and GitHub retargets the remaining PRs onto the base branch afterwards.
Stacked PRs are available for GitHub.com repositories only. See the Stacked PRs guide for how Devin creates and maintains stacks.

​
Auto-Review

Devin can automatically review PRs without you having to manually trigger it. Configure auto-review in Settings > Review. On eligible connected PRs, the actions menu (three dots in the header) lets users with the appropriate Review permissions toggle auto-review for that PR. Available settings links and controls depend on the PR and your access.

​
When Does Auto-Review Run?

Automatic review uses rules that combine a starting event, a review cadence, and optional PR conditions. Choosing PR is created can include draft PRs; choosing PR is ready waits until the PR is opened ready or marked ready.

​
Trigger Modes

Choose when a rule starts:
  • PR is created — When the PR is opened, including as a draft.
  • PR is ready — When the PR is opened ready or is marked ready.
Then choose the cadence:
  • Only once — One review when the triggering conditions are met.
  • Every push — Review again on subsequent pushes. This requires the full automatic-review usage tier.
Personal settings also offer Manual, which removes personal automatic enrollment. It does not disable reviews requested by another matching rule.

​
Self-Enrollment (All Users)

When personal enrollment is enabled for your account, users with a linked Git provider identity and the appropriate Review usage tier can enroll themselves without admin permissions.
  1. Go to Settings > Preferences.
  2. Under Devin Review, choose Auto review PRs created or Auto review PRs ready for review.
  3. Set Review cadence to Only once or Every push, if your permissions allow it.
Devin reviews eligible PRs you author in connected repositories it can access. If the setting shows advanced filters, manage the underlying rule in Review settings rather than replacing it with a simpler personal trigger. On eligible connected PRs, you can also turn auto-review on or off from the review page’s actions menu if your Review permissions allow it. This control is not available on every public or read-only review.

​
Review Comment Language

You can choose the language Devin Review uses for its comments and analysis from Settings > Preferences under the Devin Review section.
  • Use your display language (default) — Review comments follow your display language setting.
  • Specific language — Choose from English, Spanish, Portuguese, Japanese, Chinese, Korean, French, German, Russian, Arabic, Hebrew, or Indonesian.
Language instructions in your REVIEW.md take precedence over this setting. If your REVIEW.md specifies a language for review comments, Devin will use that language regardless of your personal preference.

​
Admin Configuration

Review managers configure automatic review rules from Settings > Review. Accounts with the updated tabbed layout find these on the Review tab. Account Review managers can also enable Add “Devin Review” link in PR description (on by default) to add a link and review status to the PR description.

​
Scoped Rules and Exclusions

Add a rule to select a repository or another permitted scope, then narrow it with conditions such as author, label, title, source or target branch, changed files, or diff size. Choose its starting event and cadence. The rule’s Review effort can use the account default or override it with Normal or Ultra. Use exclusions for PRs the feature should not process. Matching exclusions take precedence over its enrollment rules. The Author type condition offers User, Bot, and Devin filters. Automatic review, each custom reviewer, and Autoapprover have separate rules. Enabling ordinary automatic review does not enable every custom reviewer or Autoapprover. An Autoapprover exclusion does not disable ordinary automatic review. Rules replace the earlier repository and personal enrollment lists. Old legacy enrollment entries no longer launch reviews; configure the corresponding rules instead.

​
Posting to GitHub

Account Review managers can configure what Devin posts back to the connected Git provider from Settings > Review. The section is labeled Post findings to your provider, or Post as PR comments in older layouts:
  • Post CI check (or Post GitHub CI checks in the earlier layout) — When enabled (default), Devin creates a Devin Review commit status on supported providers for each review. Passing condition chooses when it passes: review completed (default), threads are resolved, or no findings.
  • Bugs — Post bugs (likely errors or incorrect behavior) as PR comments.
  • Security — Post security vulnerabilities and hardening suggestions as PR comments.
  • Flags (investigate) — Post investigate flags (potential issues worth a closer look) as PR comments.
  • Flags (note) — Post informational flags (observations that may not require action) as PR comments.
By default, bugs and security findings are posted as PR comments. Investigate and informational flags are not posted by default. Admins can toggle each finding type independently. When Scope overrides is available, override the default posting categories for a repository or supported repository scope. This controls what is posted, not whether a review runs. Choosing no categories suppresses finding comments for that scope.
Enterprise accounts: Settings apply across all organizations in the enterprise. Account-wide posting controls require account-level Manage Review; organization-level rule management does not grant permission to change these defaults.
Auto-review is not available for public repos that aren’t connected to your organization.

​
Bug Catcher

The Bug Catcher automatically analyzes your PR for potential issues and displays findings in the Analysis sidebar or Bugs view. Findings include Bugs, Flags, and Security. Beta custom reviewers have their own attributed findings.

​
Bugs

Bugs are actionable errors that should be fixed in the code. These represent issues the Bug Catcher has high confidence are actual problems. Bugs are displayed with two severity levels:
  • Severe — High-confidence issues that require immediate attention
  • Non-severe — Lower severity issues that should still be reviewed
When you see a bug, you should investigate and fix it in your code. Bug findings keep the summary concise. When available, expand Learn more for a detailed explanation, a concrete example, and a recommended fix. The copy button copies the whole finding, including its location, explanation, and any suggested code change.

​
Flags

Flags are informational code annotations that may or may not require action. They come in two classes:
  • Investigate — Flags that warrant further investigation. You should review the flagged code yourself and verify whether there is an actual bug or issue.
  • Informational — The Bug Catcher has either concluded correctness or is explaining how something works. These help you understand the code changes without requiring action.

​
Security

Devin Review scans for security vulnerabilities and displays them alongside other findings. Security scanning is part of a full review; use the posting settings to control whether security findings are posted as PR comments. A diff-only analysis, such as when automatic review is paused by a spending limit, is not a completed security review. The scanner checks for the following vulnerability categories:
  • Injection (SQL, XSS, command, template)
  • Auth flaws (missing/broken access control, privilege escalation, auth bypass)
  • Secrets exposure (hardcoded keys, tokens in logs, credentials in source)
  • SSRF and path traversal
  • Insecure deserialization, prototype pollution
  • Missing input validation on untrusted data
  • Weak cryptography (algorithms, key management)
  • Transport/cookie security (missing HTTPS enforcement, permissive CORS, insecure cookie flags)
  • Insecure defaults or misconfigurations introduced by the PR
Findings are displayed with two severity levels:
  • Critical — High-confidence vulnerabilities that should be fixed before merging
  • Warning — Potential security weaknesses worth investigating
Each finding includes a description of the issue, a recommendation for how to fix it, and where applicable a CWE identifier classifying the vulnerability type. The security scan also respects any security-related instructions in your instruction files — for example, you can add security policies, sensitive areas, or threat models to your REVIEW.md to guide what the scanner looks for.

​
Resolving Findings

You can mark bugs, flags, and security findings as resolved once you’ve addressed them or determined they don’t require action. Resolved items are dimmed in the sidebar and sorted to the bottom of each section. Use the finding filters to focus on categories or unresolved issues, mark findings read or unread, and quote a finding into chat to ask a follow-up. On subsequent reviews, Devin checks for duplicate and resolved findings rather than treating every result as new.

​
Review Actions

​
Triggering a Review from a PR Comment

You don’t need to enable auto-review on a repository to get a review. Comment /devin review on any GitHub pull request and Devin reviews that PR, then replies on the PR with a link to the review. This works on any repository covered by your organization’s GitHub App installation — including repos that aren’t enrolled in auto-review — and is the quickest way to try Devin Review on a one-off PR. Requirements and behavior:
  • Comment exactly /devin review at the start of the comment. The command is case-insensitive, and works in both PR conversation comments and inline review comments.
  • Write access required — the commenter needs write or admin permission on the repository, and their GitHub account must be linked to their Devin account. Outside contributors can’t trigger reviews.
  • Open PRs only — comments on closed or merged PRs are ignored.
  • GitHub only — including GitHub Enterprise Server and Enterprise Cloud. GitLab supports auto-review but not the comment trigger.
Other /devin comments (for example /devin fix the failing test) start a regular Devin session on the PR instead of a review. See Start Devin from a PR comment.

​
Starting a Review

When creating a new inline comment or replying to an existing thread, you can check the Start a review checkbox to batch your comments into a pending review instead of posting them individually. This mirrors the GitHub review workflow, letting you collect all your feedback before submitting. Once a review is in progress, subsequent comments are automatically added to it and the checkbox is hidden.

​
Resolving Comments

You can resolve review threads to indicate they’ve been addressed. When all threads in a bot-authored review are resolved, Devin automatically minimizes that review on GitHub to keep the PR conversation clean. If a thread is later unresolved, the review is automatically unminimized. In the diff view, you can expand or collapse individual comment threads using the caret toggle to focus on outstanding feedback.

​
Code Owner Indicators

When a code owner has been requested as a reviewer, Devin Review displays a shield icon next to their name in the reviewer sidebar with a “Requested as code owner” tooltip. This makes it easy to identify which pending reviewers have code ownership over the changed files.

​
Custom Reviewers (Beta)

Custom reviewers are in Beta and require beta access.
A custom reviewer checks PRs against instructions you write and produces findings attributed to that reviewer. Use one for a focused concern, such as API compatibility, database migrations, accessibility, or test requirements. Use review context for shared background and conventions, and a custom reviewer when you want a named check with its own instructions, findings, and enrollment rules.

​
Create a Reviewer

  1. Open Settings > Review and find Custom reviewers. Some accounts show reviewers as a section rather than a separate tab.
  2. Select Add reviewer and enter a Name and optional description.
  3. Under Instructions, choose Plain text and describe what to check and what to ignore, or choose Repository skill or Organization skill (Enterprise skill in an enterprise) to drive from an existing skill.
  4. Choose Finding urgency: Severe for problems that must be fixed, Moderate for flags worth investigating, or Info for suggestions and context.
  5. Select Create and enable, or Save as draft to finish later.
  6. Open the reviewer and add a rule under Rules to select which PRs it checks.
An enabled reviewer with no matching rules does not run. Draft or disabled reviewers do not run even if their rules match. Matching exclusions take precedence over rules. For example, create an API compatibility reviewer for your API repository:

​
Reuse a Skill

A reviewer created from a Repository skill follows that skill on the repository’s default branch (usually main or master): its instructions are read-only in the reviewer and update as new versions of the skill are pushed.
In an enterprise, reviewers are shared. Check the audience before copying an organization skill: users who can manage Review in other organizations may be able to read the copied instructions.

​
Findings and CI Checks

Findings carry the reviewer’s name and configured urgency. The run history is available for each reviewer with the count of fixed and ignored findings. Newer beta versions also offer a CI check section. If available, choose Part of Devin Review or a Separate check, such as Devin Review / API compatibility. A separate check can pass when:
  • Reviewer finishes — completion is enough, even if it found issues.
  • All comments are resolved — its posted comments have been resolved.
  • There are no open findings — its findings are closed.
Separate checks require the account’s Post CI check setting. If it is off and you cannot enable it, ask an account administrator. Posting a check does not make it a merge requirement: configure the displayed check as required in your repository’s branch rules to block merges. Disable a reviewer to stop future runs while keeping its configuration. Archiving also removes it from the list; findings it already posted are kept.

​
Autoapprover (Beta)

Autoapprover is in Beta and requires beta access.
Autoapprover evaluates whether selected PRs can be approved without human review. It either approves the reviewed commit or leaves the PR for a person to review. Custom instructions are optional. Once you enable Autoapprover for selected PRs through a rule, it works out of the box using a built-in rubric:
  • Intent: Does the change match the PR author’s stated intent?
  • Code quality: Does the change keep the codebase maintainable and easy to review?
  • Incident risk: Could a problem in the change cause a reliability or security incident?
Autoapprover considers the review’s findings alongside this rubric. You do not need to write a prompt before using it.
Autoapprover posts real approvals. Start with a narrow scope and inspect its decisions before expanding. It does not merge PRs itself, but an approval can satisfy a repository requirement and let an existing auto-merge or merge queue configuration proceed.

​
Set Up Autoapprover

  1. Open Settings > Review and find Autoapprover.
  2. Add an Autoapprover rule selecting the repository and PR conditions to evaluate.
  3. Optionally, add Autoapprover exclusions for PRs you never want it to evaluate.
A matching rule is required; custom instructions are not. Autoapprover evaluates enrolled PRs on every push, and matching exclusions take precedence. Incremental evaluations consider the previous decision and new changes, with a full reassessment when needed.

​
Optional Custom Instructions

To tailor the default rubric, select Add instructions under Instructions and choose where they apply. Describe what your team is comfortable approving automatically and what always needs a person. For the criteria they address, these instructions take precedence over the default rubric; if instructions conflict, the narrower scope takes precedence. Instructions guide decisions but do not enroll PRs by themselves. For example, after adding a rule limited to a documentation repository, you could optionally add:
Use exclusions for firm enrollment boundaries. Instructions are guidance to an AI reviewer, not a substitute for branch protection or access controls.

​
Understand the Result

The PR’s Autoapprover section shows its result and reasoning:
  • Autoapproved — Devin approved the PR.
  • Not autoapproved — the PR needs human review.
  • Approved by a person — a human has supplied an approval.
If a later completed evaluation changes the decision, Autoapprover can withdraw its earlier approval. If it cannot update the approval, the UI asks you to check the PR for a standing approval from Devin. A failed or skipped evaluation is not confirmation that an earlier approval was withdrawn. GitHub restricts PR authors from reviewing their own PRs. For that reason, make sure Devin opens GitHub PRs under your own name (link your GitHub account) before they can be approved by Devin. Removing a rule stops future evaluations of PRs matched only by that rule; it does not imply that approvals already posted have been revoked. If a result is unexpected, check the approval on the Git provider, narrow the rule, and send your Cognition representative the PR link and relevant instructions.

​
Auto-Fix

Auto-Fix uses a Devin session to address review findings on a PR. It is different from applying an individual suggested edit or asking the Review chat agent to prepare a commit.

​
How to Enable It

For a PR already owned by a Devin session, there are two ways to enable automatic responses to review feedback:
  1. From the review sidebar — When Enable auto-fix is available on a Devin-owned PR, selecting it allows responses to Devin Review feedback for Devin PRs in that organization. This requires permission to manage the organization’s settings.
  2. From global Devin settings — Go to Settings > Devin > Pull requests > Responding to bots, then either:
    • Set the mode to Selected only and add devin-ai-integration[bot] to the allowlist, or
    • Set the mode to All bots.
For a PR without a linked Devin session, Auto-fix with Devin can start a session to take over the PR and address detected bugs and failing required CI checks. You need permission to create the session and access its repository. In the account-wide workspace, select an environment or outpost first. The resulting session and its commits are linked from the review.
Enabling automatic responses changes the relevant bot allowlist, not just the current PR. Account-wide sessions use account settings; organization sessions use their organization’s settings. If you cannot change those settings, a one-off fix session can still be available without enabling future automatic responses.

​
Findings on Devin’s own PRs

For accounts with direct finding triage enabled, an eligible session that opened the PR can address findings before they are posted individually:
  1. The PR shows a Devin is addressing Devin Review findings status.
  2. If responses to Devin Review are allowed and PR monitoring is active, the session fixes what it can and records its decisions.
  3. Only the findings Devin could not fix are posted as review comments, and the status lists what was fixed.
This flow requires an eligible running or suspended session that created the PR, not merely one that took it over. If there is no eligible session, or automatic responses are not allowed, findings are posted to the PR for review instead. Availability varies by account and provider.

​
Permissions & Constraints

  • Changing automatic-response settings requires the relevant organization or account settings permission.
  • If the bot mode is set to All bots, Auto-Fix shows as enabled and cannot be changed from the review sidebar. Use Customization settings to modify the bot mode.
  • Devin Review’s No Issues Found summary comments are always ignored. Only comments with actual findings trigger Auto-Fix.
If Devin Review feedback is currently ignored in your repository, you’ll see a prompt in the session timeline to enable it.

​
Commit & Comment Attribution

  • Bug findings, flags, and automated annotations always appear as the Devin bot.
  • When a user writes a comment or review through Devin Review, it appears under the user’s GitHub identity.
  • When a user asks the chat agent to make a code change, the resulting commit is made as the Devin bot.
  • GitHub Suggested Changes follow standard GitHub behavior: any reviewer (including Devin) can leave a suggested edit in a review comment. Applying a suggestion is separate from starting an Auto-Fix session.
  • Devin will never create commits or comments on behalf of a user without the user explicitly initiating the action.

​
AGENTS.md / Instruction Files

Devin Review respects instruction files in your repository. If any of these files exist, they’ll be used as context when analyzing your PR:
  • **/REVIEW.md
  • **/AGENTS.md
  • **/CLAUDE.md (case-insensitive)
  • **/CONTRIBUTING.md (case-insensitive)
  • .cursorrules
  • .windsurfrules
  • .cursor/rules
  • *.rules
  • *.mdc
  • .coderabbit.yaml / .coderabbit.yml
  • greptile.json
Files inside agent-like subdirectories (.agents/, .devin/, agents/, .cursor/, .github/) are treated as belonging to the parent directory for scoping purposes. For example, src/.agents/REVIEW.md applies to files under src/. These files can contain coding standards, project conventions, or other guidelines that help provide more relevant feedback.

​
Custom Review Rules

You can configure additional files to be read as review context from Settings > Review under Context. These file patterns are separate from custom reviewers: they supply background information rather than defining a reviewer that produces its own findings. To add repository files:
  1. Find Context in Review settings (on the Review tab if your account has the tabbed layout).
  2. Select Add context. This opens Add repository files directly, or offers a menu where you can choose Repository files.
  3. Enter a file glob pattern, such as docs/architecture/**/*.md, and add it.
Patterns apply across the account and read matching files from the repository being reviewed, closest to the changed files first. Edit or remove custom patterns from the list.

​
Review-Context Instructions (Beta)

Written review-context instructions are in Beta and require beta access. Repository instruction files remain available independently.
Use review-context instructions for guidance you want to manage centrally without adding files to your repositories.
  1. Open Settings > Review and find Context.
  2. Open the add menu and choose Instructions, marked Beta.
  3. Enter a title and the review guidance.
  4. Choose All repositories or a narrower repository scope.
  5. Select Add context.
For example:
Edit or remove an entry when the guidance changes. Managing these instructions requires account-level Manage Review permission. Use repository files instead when the guidance should be version-controlled alongside code.

​
REVIEW.md

REVIEW.md is a dedicated instruction file for Devin Review. Place it anywhere in your repository to customize how Devin reviews PRs in your project. Devin automatically picks up REVIEW.md files at any directory level (**/REVIEW.md), so you can scope review guidelines to specific subdirectories if needed. Use REVIEW.md to define review-specific guidelines such as:
  • Areas of the codebase that need extra scrutiny
  • Common pitfalls or anti-patterns to watch for
  • Project-specific conventions that reviewers should enforce
  • Files or directories that can be safely ignored during review
  • Security or performance considerations unique to your project
Example REVIEW.md: