Setting Up GitHub Copilot Code Review Policies for Different Repositories

When multiple development teams work across different repositories, maintaining consistent code review standards becomes difficult. One repository may contain an ASP.NET Core application, another may contain an iOS application, and another may manage infrastructure using Terraform.

Each project has different requirements, but some review expectations should remain consistent across the organization.

GitHub Copilot code review helps automate part of this process. It can examine pull requests, identify potential issues, suggest improvements, and use repository-specific instructions to understand how a project should be reviewed.

However, enabling Copilot code review for every repository with identical settings is not always the right approach.

A production API may need deeper security and performance reviews, while a documentation repository may only need basic checks for broken examples and formatting.

In this article, we will look at how to configure GitHub Copilot code review policies at the organization and repository levels, create custom review instructions, and apply different standards to different projects.

Understanding GitHub Copilot Code Review

GitHub Copilot code review analyzes changes in a pull request and provides feedback directly within the pull request conversation.

It can help identify:

Potential bugs and incorrect logic.
Security weaknesses.
Performance problems.
Missing error handling.
Code maintainability issues.
Problems with implementation patterns.

Copilot can also use repository context and custom instructions to make its feedback more relevant to the project.

For example, consider two repositories:

Repository	Review requirements
Customer API	Authentication, authorization, SQL queries, validation, and performance
iOS Application	Swift concurrency, memory management, UI responsiveness, and error handling
Infrastructure	IAM permissions, network exposure, configuration, and resource security
Documentation	Code example accuracy, broken references, and consistency

A single general instruction cannot describe all these requirements effectively.

The better approach is to define common review expectations and add specialized instructions for each repository.

Understand the Different Configuration Levels

GitHub provides multiple levels for managing Copilot code review.

The main configuration levels are:

Configuration level	Purpose
Enterprise	Establishes policies across the enterprise
Organization	Defines defaults and controls for organization repositories
Repository	Configures review behavior for an individual repository
Custom instructions	Defines project-specific review expectations

These levels serve different purposes.

Enterprise and organization settings help administrators control availability, review effort, billing, and other policies.

Repository settings allow teams to customize how Copilot reviews their pull requests.

Custom instruction files explain the coding standards and technical requirements that Copilot should consider while reviewing code.

For a company managing multiple repositories, these settings should work together rather than being maintained independently.

Configure Automatic Code Reviews at the Organization Level

An organization administrator can configure automatic Copilot code reviews for selected repositories using GitHub rulesets.

This is useful when a company wants Copilot to review pull requests without requiring every developer to request a review manually.

The configuration process is:

Open the GitHub organization.
Navigate to Settings.
Open Repository and select Rulesets.
Create a new branch ruleset.
Select Active as the enforcement status.
Configure the target repositories using inclusion or exclusion patterns.
Select the branches that should be covered.
Enable Automatically request Copilot code review.
Configure whether Copilot should review new pushes and draft pull requests.
Save the ruleset.

Repository targeting is particularly useful when different teams maintain separate projects.

For example, you could create one ruleset for backend repositories and another for mobile repositories.

A repository pattern can help identify which projects should receive a particular policy.

The important point is that the ruleset controls when Copilot reviews a pull request. It does not replace the custom instructions that explain what Copilot should look for.

Configure Different Review Effort Levels

Not every pull request requires the same depth of analysis.

GitHub Copilot code review provides different review effort levels.

Review effort	Intended use
Lite	Standard review for routine changes
Balanced	Deeper analysis of complex logic and security-sensitive changes
Max	More intensive analysis for changes requiring additional scrutiny

For example, a small documentation update may not need the same review effort as a change to payment processing or authentication.

You can configure the default review effort at the organization level and allow repository administrators to choose a lower or higher level within the configured limits.

An organization can also define a maximum review effort to prevent individual repositories from exceeding its resource and cost policies.

A practical configuration could look like this:

Repository type	Suggested review effort
Documentation	Lite
Internal tools	Lite or Balanced
Customer-facing APIs	Balanced
Authentication services	Balanced or Max
Payment processing	Max

These are suggested starting points, not mandatory settings. The appropriate level depends on the complexity and risk of the codebase.

Balanced and Max reviews can consume more AI credits, so review effort should be selected according to the value of additional analysis.

Create Repository-Wide Custom Instructions

Review effort controls the depth of analysis, but it does not explain your project's architecture or coding standards.

For that, GitHub supports repository-wide custom instructions.

Create the following file in your repository:

.github/copilot-instructions.md

This file contains natural-language instructions that Copilot can use during code reviews.

For example, consider an ASP.NET Core application using C# and SQL Server.

A suitable instruction file could look like this:

# Code Review Guidelines

Review all changes with production reliability,
security, and maintainability in mind.

## C# and .NET

- Follow existing project architecture.
- Use asynchronous methods for I/O operations.
- Avoid blocking calls such as Task.Result and Wait().
- Validate external input.
- Use dependency injection consistently.
- Handle exceptions appropriately.

## Database

- Check SQL queries for injection vulnerabilities.
- Review transaction handling.
- Identify unnecessary database calls.
- Check whether indexes are appropriate for frequently
  executed queries.
- Avoid exposing database credentials.

## API Security

- Verify authentication and authorization.
- Validate request models.
- Avoid exposing sensitive information in responses.
- Review logging statements for confidential data.

## Testing

- Check whether new functionality has appropriate tests.
- Identify missing error-handling scenarios.
- Review boundary conditions.

The instructions should describe actual project requirements rather than generic recommendations.

For example, if the application uses Dapper instead of Entity Framework Core, include relevant database access conventions.

This makes the review more useful because Copilot has additional context about the technologies and practices used by the project.

Apply Different Instructions to Specific Files

Some repositories contain multiple technologies and architectural layers.

Consider a repository with the following structure:

MyApplication/
│
├── .github/
│   ├── copilot-instructions.md
│   └── instructions/
│       ├── api.instructions.md
│       ├── database.instructions.md
│       └── tests.instructions.md
│
├── Controllers/
├── Services/
├── Data/
├── Models/
└── Tests/

A single repository-wide instruction file may become too large or too general.

GitHub supports path-specific custom instructions through files ending with .instructions.md.

These files are stored under .github/instructions/ and use an applyTo property to identify the files they apply to.

For example, create api.instructions.md:

---
applyTo: "Controllers/**/*.cs,Services/**/*.cs"
---

# API Review Instructions

- Validate all incoming request data.
- Verify authentication and authorization.
- Check HTTP status codes.
- Avoid exposing internal exception details.
- Use asynchronous I/O operations.
- Check cancellation token propagation.
- Review API response consistency.

For database-related files, create database.instructions.md:

---
applyTo: "Data/**/*.cs,Database/**/*.sql"
---

# Database Review Instructions

- Check SQL queries for injection vulnerabilities.
- Verify parameterized query usage.
- Review transaction boundaries.
- Identify unnecessary database queries.
- Check connection and resource handling.
- Review migration scripts for data loss risks.

For tests, create tests.instructions.md:

---
applyTo: "Tests/**/*.cs"
---

# Testing Review Instructions

- Verify positive and negative scenarios.
- Check boundary conditions.
- Avoid tests that depend on execution order.
- Verify exception handling.
- Check whether assertions validate the expected behavior.

When a changed file matches a path-specific instruction, Copilot can use those instructions along with the repository-wide instructions.

This approach allows a single repository to maintain different review standards for different parts of its codebase.

Configure Different Policies for Different Repositories

Consider an organization maintaining three repositories:

Company/
│
├── customer-api/
├── ios-application/
└── infrastructure/

Each repository has different technical requirements.

You can organize the configuration as follows.

Repository	Automatic review	Custom instructions	Review focus
customer-api	Enabled	API and database rules	Security, performance, validation
ios-application	Enabled	Swift and iOS rules	Concurrency, memory, UI
infrastructure	Enabled	Infrastructure rules	IAM, network security, configuration

For the iOS application, the repository-wide instructions could include:

# iOS Code Review Guidelines

- Follow existing Swift and SwiftUI architecture.
- Avoid unnecessary force unwrapping.
- Check Swift concurrency and actor isolation.
- Review memory management and retain cycles.
- Avoid blocking the main thread.
- Handle asynchronous errors correctly.
- Check accessibility for user interface changes.
- Review API response handling and state updates.

For infrastructure code, the instructions could include:

# Infrastructure Code Review Guidelines

- Follow least-privilege access principles.
- Avoid publicly exposing sensitive resources.
- Check IAM permissions.
- Review network security configurations.
- Avoid hardcoded credentials.
- Verify encryption settings.
- Check resource dependencies and deletion behavior.

The organization can maintain common review policies while allowing each repository to define its own technical expectations.

This is more manageable than maintaining one large instruction file for every project.

Control Copilot Approvals and Merge Requirements

Copilot code review can also be configured to submit approving reviews.

GitHub provides settings to control whether Copilot can approve pull requests and whether those approvals can count toward merge requirements.

These settings should be considered carefully.

For example, a team may allow Copilot to provide review feedback but require human approval before merging production changes.

A reasonable approach is:

Repository type	Suggested approval policy
Documentation	Human approval based on team requirements
Internal utilities	Human review for significant changes
Customer APIs	Human approval required
Security-sensitive services	Human approval required
Infrastructure	Human approval required

AI-generated review feedback should not be treated as proof that a change is safe.

Even when Copilot identifies useful problems, it can miss issues or produce incorrect suggestions. Human reviewers should remain responsible for architectural decisions, business logic, and production readiness.

Also distinguish between an approving review and a required human review. Configure branch protection and rulesets to enforce the actual approval requirements of your organization.

Test Your Copilot Review Configuration

After configuring the policies and instruction files, test them with representative pull requests.

For example, create a small change that introduces an issue relevant to the repository.

For an API project, you could introduce an unvalidated request field or an inefficient database operation.

For an iOS project, you could introduce an unnecessary force unwrap or an unsafe concurrency pattern.

Then request a Copilot code review and examine its feedback.

Check whether:

The review identifies relevant issues.
Repository-wide instructions are followed.
Path-specific instructions are applied to matching files.
The review effort is appropriate.
Automatic reviews are triggered as expected.
Human approval requirements remain enforced.

Also review false positives. If Copilot repeatedly reports an intentional implementation pattern as a problem, improve the instructions by explaining the relevant architectural decision.

Keep the instructions focused. A large collection of overlapping rules can make reviews less useful.

Common Configuration Mistakes

Several configuration mistakes can reduce the effectiveness of Copilot code review.

Mistake	Better approach
Using identical instructions for every repository	Define common standards and repository-specific rules
Adding every requirement to one instruction file	Use path-specific instruction files
Enabling automatic reviews without testing	Validate the configuration with representative pull requests
Choosing the highest review effort everywhere	Match review effort to code risk and complexity
Treating Copilot approval as human approval	Preserve required human review policies
Writing vague instructions	Include concrete checks and project conventions
Ignoring usage costs	Monitor AI credit consumption and review frequency

Another common mistake is expecting custom instructions to enforce security policies.

Instructions guide Copilot's analysis, but they are not deterministic security controls. Use dedicated security scanning, automated tests, branch protection, and required status checks for controls that must be enforced consistently.

Summary

GitHub Copilot code review becomes more useful when its configuration reflects the requirements of each repository.

Organizations can use rulesets to enable automatic reviews across selected repositories, configure review effort levels, and establish common policies. Repository-wide and path-specific instruction files provide additional context about architecture, coding standards, security requirements, and testing expectations.

For organizations managing multiple technologies, this approach provides a practical way to standardize code review without forcing every development team to follow identical technical rules.

The goal is to make Copilot reviews relevant to the codebase, reduce repetitive review work, and help developers identify potential problems earlier while keeping human reviewers responsible for important engineering decisions.