Skip to main content
Gitar reads its per-repository configuration out of your codebase: AI instruction files, custom review instructions, and automation rules. All of it is version-controlled alongside the code it applies to.

​
AI Instruction Files

Gitar recognizes the following files as AI instruction sources: Both rule directories are read one level deep, so a rule at .claude/rules/backend/api.md is not picked up. Keep rule files directly in the directory. When Gitar processes a PR, it reads these files to understand your repository’s conventions, coding standards, and best practices. This context is used during both code review and CI failure fixing.
These files are read automatically, with no additional configuration needed. Gitar loads them from your repository root on every PR. When the agent works inside a subdirectory during a run, it also picks up instruction files and rule directories between that subdirectory and the root.

​
The .gitar Directory

The .gitar directory is the primary location for Gitar-specific configuration:
.claude/skills/, .agents/skills/, and .github/skills/ are read as well, so skills already kept for Claude Code, Codex, or Copilot need no second copy. AI instruction files, skills, .gitar/rules/, .gitar/review/ and .gitar/instructions/ can live in configuration repositories instead of being committed to each repository. Select up to three configuration repositories and every repository in the organization reads their shared configuration alongside its own. The criteria files under .gitar/config/ stay per repository, since their whole point is to differ.

​
Custom Review Instructions

The .gitar/review/ directory lets you tailor Gitar’s code review to your project’s specific requirements. Add one or more markdown files containing instructions, checks, or gotchas that Gitar should consider during reviews. Multiple files can organize instructions by topic, for example separate files for security rules, performance guidelines, and project-specific gotchas. Example: A file named .gitar/review/gotchas.md that documents codebase-specific patterns:

​
Including Specific Files

You can include content from other files using the @ syntax with a relative path. Paths are first resolved relative to the source file, with a fallback to the repository root if not found. Example: Given the following directory structure:
From .gitar/review/gotchas.md, you can include files using either approach:
  • @../rust_best_practices.md - resolved relative to gotchas.md, one level up from review/
  • @shared/common_rules.md - not found relative to review/, so falls back to repo root resolution
This works recursively, so an included file can itself include other files.

​
Repository Rules

Repository rules let you create automated workflows using natural language, specified in .gitar/rules/*.md files. When conditions defined in the rule are met on a PR, Gitar automatically executes the specified actions. See the Repository Rules documentation for full details, syntax, and examples.

​
Organization-Level Settings

Organization-level settings set the defaults every connected repository starts from. See Settings for what they cover.