Skip to main content
Select up to three configuration repositories. Every repository in the organization inherits their shared configuration. Gitar reads shared configuration and AI instruction files from each selected repository’s default branch alongside the repository under review’s own configuration. Teams can keep their shared files in separate repositories.

​
Before you begin

  • The configuration repository is available on the Pro and Enterprise plans. It is being rolled out per organization, so contact support if you do not see the picker.
  • You need the organization admin role.
  • The repository has to be connected to Gitar already. AWS CodeCommit repositories are not selectable.

​
What it holds

Shared configuration includes these paths: Local rules and skills take precedence. Among shared repositories, the first selected repository wins a duplicate rule or skill. The settings list shows that order. Instruction files combine guidance from every selected repository, followed by local instructions. They share the existing instruction budget, so adding repositories does not multiply that budget. A local instruction file does not replace shared instructions. All selected repositories apply organization-wide. GitLab group assignments are not supported.

​
Set the configuration repository

1

Create or pick a repository

Any connected repository works. A repository named .gitar is a clear place for it.
2

Commit your shared configuration to it

The same paths a repository uses for its own:
Add whichever you need. See Writing a skill, Rules and Custom review instructions for each file format. Push to the default branch.
3

Name it in settings

Go to Settings -> Configuration. At the foot of the Repositories card, under Configuration repositories, select Add repository and pick a repository. Repeat for up to three repositories.
4

Confirm what Gitar found

Saving reads the selected repositories and lists discovered skills under each repository. Connection and read failures appear separately for each selection.The list shows skills only. Inherited rules and review instructions are not listed on the card, so confirm those on the next run in a repository that inherits them.
Select Remove beside a repository to stop inheriting from it. Select Clear all to stop inheriting shared configuration.

​
Where Gitar looks

Automation rules come from .gitar/rules/ and custom review instructions from .gitar/review/. Both are read recursively, so subdirectories work. Gitar also reads the same AI instruction files as in a local repository, including CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/ and .claude/rules/. These load automatically from the configuration repository’s root. Both rule directories are read one level deep. Keep shared Claude rules directly in .claude/rules/. No symlink to .gitar/review/ is needed. These files provide instructions, while .gitar/rules/ defines automation workflows. Skills have six directories, in this order:
The first four are the same directories Gitar reads in any repository. See Where skills live for the precedence rule. The last two are the Claude Code and Copilot marketplace layouts, read only in the configuration repository, so a marketplace repository works as-is. A repository’s own copy wins. Commit a skill under .gitar/skills/ with the same name as an inherited one and the local version is what runs.

​
When changes take effect

A push to the default branch can take up to 15 minutes to reach the next run. To test an edit before it lands, open a PR in the configuration repository itself. Gitar reviews that PR against the version on its branch rather than the version on the default branch.
Anyone who can push to your configuration repository can change what every Gitar agent in your organization does. Skills, rules and review instructions are all instructions the agent follows, and a skill directory can carry scripts the agent runs.Protect its default branch the way you protect CI configuration: require review, and restrict who can merge.

​
Troubleshooting

A failed fetch does not fail the review or prevent other selected repositories from loading. The card shows the connection state and the last save-time read.

​
An inherited rule never runs

Check the repository under review for a rule file of the same name under .gitar/rules/, which takes precedence. Then check that the repository runs its own rules at all. Inherited rules need the same plan as committed ones, so if .gitar/rules/ in the repository does nothing, the configuration repository’s will not run either. See Debugging for the rest.

​
An inherited skill never runs

Check the repository under review for a skill of the same name, which takes precedence. Then check the name against the slugs Gitar holds for integrations, like jira, linear and slack. A skill named after one is dropped, whether or not you have that integration on, so rename it. After that, see Why is my skill not being used?.