CODEOWNERS starter for repositories with AI coding agents

Replace the @your-org/... teams with real teams or users that have write access to the repository. Delete the paths you don't have, and this note.

A CODEOWNERS file names who must review changes to which paths. With coding agents opening pull requests, it is the simplest way to make sure the files that can do the most damage always get a review from someone who knows them. This starter uses GitHub syntax, which GitLab also reads.

# CODEOWNERS starter: owners for the paths an AI agent should not change alone.
# Order matters: for each file, the LAST matching line decides its owners.
# Keep the catch-all first and the most specific paths last.

# Everything: the team that owns the repository.
*                               @your-org/maintainers

# Pipelines and automation. A changed workflow can leak secrets or skip checks.
/.github/workflows/             @your-org/platform
/.gitlab-ci.yml                 @your-org/platform
/.forgejo/workflows/            @your-org/platform

# Infrastructure as code and deployment.
/infra/                         @your-org/platform
/deploy/                        @your-org/platform
*.tf                            @your-org/platform
/Dockerfile                     @your-org/platform

# Authentication, sessions and permissions.
/src/auth/                      @your-org/security
/src/**/permissions*            @your-org/security

# Database schema and migrations. An applied migration should never be edited.
/migrations/                    @your-org/data
/src/**/schema/                 @your-org/data

# Dependencies and lockfiles. New packages are supply-chain decisions.
package.json                    @your-org/platform
bun.lock                        @your-org/platform
package-lock.json               @your-org/platform
pnpm-lock.yaml                  @your-org/platform
requirements*.txt               @your-org/platform
pyproject.toml                  @your-org/platform
go.mod                          @your-org/platform
Cargo.toml                      @your-org/platform

# Agent configuration: prompts, rules and tool settings that steer coding agents.
/AGENTS.md                      @your-org/maintainers
/CLAUDE.md                      @your-org/maintainers
/.cursor/                       @your-org/maintainers

# This file. Without an owner, anyone could remove the rules above.
/.github/CODEOWNERS             @your-org/maintainers

How to adopt it

1. Start from real paths. List the directories where a wrong change would cost the most: pipelines, infrastructure, authentication, migrations, dependency manifests. Delete the starter's lines for paths you don't have.
2. Use teams, not people. A team survives holidays and leavers. On GitHub, owners must have write access to the repository, and a team must be visible.
3. Turn on enforcement. The file only requests reviews until you require code owner approval on the protected branch. On GitHub, approval from any one listed owner satisfies the rule.
4. Own the file itself. The last line stops a pull request, from a person or an agent, from quietly removing its own reviewers.
5. Check it parses. On GitHub, invalid lines are skipped, and a user or team without the right access is not assigned. Open a test pull request that touches each protected path and check that the right owners were requested.

Syntax to avoid

GitHub CODEOWNERS follows most .gitignore rules, with exceptions that trip people up:

• ! to negate a pattern doesn't work.
• [ ] character ranges don't work.
• Escaping a pattern that starts with # using \ doesn't work.
• Paths are case-sensitive.

GitLab code owners need the Premium or Ultimate tier. GitLab adds sections, such as [Database][2] @your-org/data, where the number is how many approvals the section needs. Within each section the last matching line wins. See the GitHub code owners docs and the GitLab code owners docs for the full rules.