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.

​
Including other files

If your conventions already live in another file, such as guidelines.md, reference it from any of the files above with @ followed by its path. Gitar replaces the reference with that file’s content.
AGENTS.md
Paths resolve from the folder of the file that contains them, then from the repository root, and must stay inside the repository. Put each reference on its own line or follow it with a space, since trailing punctuation becomes part of the path. References inside code blocks or inline code are ignored. Included files can reference other files as well. You can also place the file in .gitar/instructions/, where every Markdown file loads for all Gitar agents.

​
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/, .gitar/instructions/ and .gitar/cross-repo.md can live in configuration repositories instead of being committed to each repository. Select up to three configuration repositories to share configuration across the organization. Shared approve.md, merge.md, and risk.md files extend the organization baseline. Each repository’s own files apply on top. apply.md stays per repository.

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