Review rules in plain language
A review rule tells the reviewer what to check. For example: “Check that changes to database pool size fit the connection budget of the linked environment.”
Each rule applies to the organization, an environment, or a repository. You can narrow it further with gitignore-style path globs, languages, or both.
A repository rule with the same key replaces the inherited one, unless an administrator has locked that rule against overrides from environments and repositories. See how to manage review rules.
Configuration that lives in the repository
A .proofline.yaml file keeps rules, reviewer guidance, and review filters beside the code. Filters select base branches, labels, and paths, and can skip generated files.
Proofline reads the file at the merge base, so a pull request cannot change the configuration of its own review. Its new settings apply to later reviews once it merges.
You can validate a draft file in the console before you commit it, as the repository configuration guide shows.
Reuse the guidelines you already write
By default, Proofline reads the agent guideline files already in your repository: AGENTS.md, CLAUDE.md, and Cursor and Copilot rules. It reads them at the merge base, and an administrator can turn this off.
You can add other files, such as docs/review.md, by path.
An organization can also let reviews read the GitHub issues a pull request links, from the repositories you allow.
Preferences learned from your replies
Proofline learns from your replies. When you reply to a finding, Proofline proposes a review preference based on that reply. You approve it once, and later reviews apply it.
Governed skills for focused checks
A governed skill describes one review task for an environment. It states the question to answer, the evidence the answer needs, and the conditions under which the reviewer must abstain.
Abstention conditions tell the reviewer when to decline rather than guess. A skill is guidance: it cannot change tools, scope, or verdict rules. Manage governed skills for each environment.
Choose the risk domains to review
The reviewer works from a catalog of 18 risk domains, including infrastructure permissions, datastore compatibility, and rollout correctness. An environment owner can switch off the ones that do not apply.
Evidence coverage stays on, so a review always reports what it could not check. Proofline can also recommend a set of domains for you to approve.
Models for each stage
Pick the model that writes hypotheses and the model that investigates them, per organization or per repository. Run them on hosted models or on your own provider key.
Questions
Can I configure Proofline with a file in my repository?
Yes. Commit a .proofline.yaml file with rules, reviewer guidance, and review filters. Proofline reads it at the merge base, so a pull request cannot change its own review.
Can a review rule exclude files from a review?
No. A rule's path and language conditions decide where its instruction applies. Review scope filters leave files out of a review.
Does Proofline read AGENTS.md and CLAUDE.md?
Yes. By default, Proofline reads AGENTS.md, CLAUDE.md, and Cursor and Copilot rules at the merge base, plus any extra paths you list. An administrator can turn this off.
Write your first review rule.
See what else you control, or connect a repository and its deployment environment.
Get Started with GitHub