Review settings
Configure when Angada reviews pull requests and which findings it posts.
Workspace admins can change AI Review settings in Settings → Review. Members can’t change these settings. The page also shows effective values, including defaults and policy-resolved values; some values are display-only.
AI Review settings
| Setting | What it controls | Default and notes |
|---|---|---|
| Review instructions | Advisory guidance Angada reads before reviewing a diff. | Up to 4,000 characters. Instructions do not override the severity floor, ignore filters, or noise budget. For repository context, see Custom context. |
| Post findings at or above | The lowest severity posted inline on the pull request. | High. Available levels: Low, Medium, High, Critical. Lower-severity findings remain in the report but aren’t posted inline. |
| Fix-with-agent badges | Which coding-agent links Angada adds to review comments. | Workspace admins choose the workspace value. Users can choose their own preference in Settings → Account → My review settings. |
| Maximum reviews per pull request | How many reviews Angada can run for one pull request in a rolling 24-hour window. | 10, shown as a read-only value. A workspace or repository policy can affect effective review settings; use the displayed effective settings to see the value that applies. |
| Request changes for blocked reviews | Whether a blocked review submits a GitHub Request changes review. | Off. When on, the request can prevent merging if the repository requires approving reviews. GitHub’s review decision is separate from Angada’s review verdict. |
Draft pull requests are skipped by default. Turn on Review draft pull requests to review them before they are marked ready. Resetting this switch restores the default.
The effective settings section also shows resolved values and their source, including repository configuration. See Configure with .angada.yml to set repository-level review behavior.
Review limits
The per-pull-request number above is a rolling cap, not a calendar-day count. Angada also enforces a rolling workspace-wide cap; its default is unlimited. That cap isn’t editable on this page, and a policy may constrain the effective value. The Effective settings section identifies the value and source that apply.
Automatic reviews also have a 150 changed-file ceiling. A manual rerun can bypass that file-count ceiling, but it remains subject to review caps and other review gates. See Limits and caps.
When a blocked review requests changes, repository permissions determine who can dismiss the GitHub review. Open the pull request’s Conversation tab and dismiss the stale review with a comment; GitHub requires an administrator or someone with write access.
Repository configuration
A repository can set review behavior in a version 1 .angada.yml at its root. Angada resolves each key independently in this order: repository file, organization file, workspace settings, then built-in defaults. Organization configuration lives in the root .angada.yml of the organization's .github repository and is read from that repository's default branch. An omitted key inherits from the next source; an explicit empty list clears that list. Unknown keys and invalid values appear as diagnostics. During a review, a malformed or unavailable file falls through while the review continues. A missing file is normal.
The version 1 JSON Schema describes the v1 key shape and marks workspace-only fields as refused; it does not mean every listed field is accepted from repository configuration. Workspace-only limits, billing, seat, and spend settings cannot be set in the file. A workspace lock keeps its value effective when a repository file offers a different value; the refusal is shown in Effective settings.
Preview and export
Admins can open Workspace settings → Review to view Effective settings, including each value, its source, locks, and rejected overrides. Enter the repository as owner/name, the pull request number, and its full 40-character head SHA, then choose Preview PR settings. The SHA pins the preview to that pull request revision.
Copy config and Download .angada.yml export the selected scope using the same resolver as the preview. A PR export includes effective repository and organization values. Show workspace settings returns to workspace values and built-in defaults. Download the file or copy its contents into .angada.yml at the repository root.
The YAML includes settings that a repository can control. Workspace-only values, lock rules, and lock metadata are omitted. A locked setting's effective value is exported as an ordinary repository value; the file cannot recreate or remove the workspace lock. Review diagnostics and refusals before adopting an export.
The per-pull-request draft override is a runtime control. It can change whether that pull request is reviewed, but it is not copied into a repository-wide export.
If the pull request head has moved, reload the pull request and preview its new SHA before exporting. A pinned preview or export fails when the root file cannot be read or parsed reliably. Fix the file or restore access and retry; Angada does not silently export workspace fallback values for that failed preview. If clipboard access fails, use Download .angada.yml.
Policy changes and reserved paths
A pull request that changes root .angada.yml, files under .github/, or shared instructions such as AGENTS.md is reviewed using the repository's base revision for policy sources. Angada withholds auto-approval for that pull request. This also applies to changes from forks. Once the policy change is merged, later pull requests that do not change policy sources use the policy at their head revision. Organization configuration continues to come from the organization's .github repository's default branch.
Version 1 reads only the root .angada.yml for repository configuration. Files under .angada/ are reserved and ignored; a review reports when that directory is detected. Root configuration continues to resolve normally when both are present. The directories section in root YAML is also reserved and does not apply per-directory overrides in version 1.