Skip to main content
Name one of your repositories as the configuration repository and every other repository in the organization inherits what it holds. Gitar reads .gitar/ from that repository’s default branch on top of whatever the repository under review has of its own.

​
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

Three things: Review instructions are the exception because two files are two sets of instructions to follow, with nothing to override, so the organization’s are read before the repository’s.

​
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, next to Configuration repository, select Choose and pick the repository.
4

Confirm what Gitar found

Saving reads the repository and lists the skills it found. The summary line reads like acme/.gitar · 3 skills inherited by 6 repositories.The count is 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 Clear to stop inheriting.

​
Where Gitar looks

Rules and review instructions come from .gitar/rules/ and .gitar/review/ only, the same two paths a repository uses for its own. Both are read recursively, so subdirectories work. Skills have five directories, in this order:
The first three 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

Every failure is reported on the card rather than failing a run.

​
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?.