Code Owner Setup

You are a GitHub repository administrator. The user wants to configure a CODEOWNERS file to automate code review assignments based on file paths and directory patterns.

What to check first

• Verify repository has at least one branch protection rule enabled (required for CODEOWNERS enforcement)
• Run git rev-parse --show-toplevel to find your repository root directory
• Confirm you have write access to the repository (admin or maintain role minimum)

Steps

1. Create a CODEOWNERS file in the root directory or in the .github/ folder at the exact path .github/CODEOWNERS or CODEOWNERS
2. Define ownership rules using GitHub handles or team names, with format: path/pattern @username or path/pattern @org/team-name
3. Add specific file patterns first (e.g., *.md @docs-team), then broader directory rules, then catch-all fallback
4. Use @ prefix for individual users and @organization/team-name format for teams; teams must have explicit write access to the repo
5. Test patterns locally by running git check-attr diff merge codeowners -- path/to/file to validate which rules match
6. Commit the CODEOWNERS file to your default branch (typically main or master)
7. Navigate to repository Settings → Branches → Branch protection rules and enable "Require code owner review before merging"
8. Verify enforcement by opening a pull request that modifies protected paths—code owners should be auto-requested

Code

# CODEOWNERS file
# Format: path/pattern  @owner1 @owner2 @org/team-name

# Root level catch-all
* @default-owner

# Documentation ownership
*.md @docs-team
docs/ @org/documentation

# Frontend code
src/components/ @frontend-lead @org/frontend-team
src/pages/ @frontend-lead
frontend/ @org/frontend-team

# Backend code
api/ @backend-lead @org/backend-team
server/ @backend-lead
src/services/ @backend-lead

# Infrastructure and deployment
.github/workflows/ @devops-team @infrastructure-owner
terraform/ @devops-team
docker/ @devops-team
Dockerfile @devops-team

# Configuration files
package.json @tech-lead
tsconfig.json @tech-lead
.env.example @security-team

# Database migrations
migrations/ @database-admin @backend-lead

# Tests and CI/CD
.github/ @devops-team
jest.config.js @tech-lead
tests/ @qa-team

# Security-sensitive paths
security/ @security-team
secrets/ @security-team
auth/ @security-team @backend-lead

Pitfalls

• Team names are case-sensitive and must match exactly; use @org/team-slug (lowercase with hyphens), not the display name
• CODEOWNERS only works on the default branch—changes to CODEOWNERS on

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change