> ## Documentation Index > Fetch the complete documentation index at: https://docs.builddown.ai/llms.txt > Use this file to discover all available pages before exploring further. # Reviewers > The reviewers AI-Implement runs after it opens a pull request: the two built-in reviewers, how a project selects which reviewers run and gate, and how to define your own in .ai-implement/config.yml. > [!WARNING] > > **Experimental version.** > > This is the latest in-development version of AI-Implement. Features may change without notice and behavior is not guaranteed. Switch to the [latest stable version here](https://docs.builddown.ai/introduction.md). AI-Implement runs a list of reviewers after it opens a pull request. Each reviewer reads the diff and reports what it finds. A reviewer either gates the merge or runs as advisory. A gating reviewer blocks the merge when it finds a problem. An advisory reviewer reports its findings but does not block the merge. ## Use Codex for internal review These controls make different choices: | Control | What it selects | | - | - | | [Review stage](https://docs.builddown.ai/latest/configuration/agents.md) | The agent, provider, model, account profile, and timeout for internal verdicts. | | **Reviewers** in project settings | Which internal reviewer definitions run and which findings gate. | | [Review process](https://docs.builddown.ai/latest/customize/external-reviewers.md#review-process) | How a separate external review service contributes its verdict and findings. | Selecting Codex for the review stage does not install an external Codex review bot. The configured stages divide the work as follows: | Work | Stage | | - | - | | Generate planning comments | planning | | Change code, including post-push fix passes | implementation | | In-loop verdicts, internal or advisory post-push reviews, and read-only post-mortems | review | For example, Claude implementation with Codex review sends code fixes back to Claude. A changed selection applies to a later run; the current run keeps its resolved settings. The configured review model takes precedence over repository model values and each reviewer definition's `model`. ## Built-in reviewers AI-Implement includes these built-in reviewers: | Reviewer | Question it asks | Default | | - | - | - | | `gap-analysis` | Does the diff implement every acceptance criterion in the issue? It also reports clearly unrequested changes. | runs and gates | | `code-review` | Does the diff contain defects, security faults, or test gaps? | runs and gates | > [!WARNING] > > Turn `code-review` off only when a trusted external reviewer is in place. See [External code reviewers](https://docs.builddown.ai/latest/customize/external-reviewers.md). ## Which reviewers run The project's **Reviewers** setting selects which reviewers run and which of them gate. A pull request cannot change this setting. When the setting is blank, both built-in reviewers run and gate. The [project settings](https://docs.builddown.ai/latest/configuration/team-repo-mappings.md) page describes this control. ## Define a reviewer You can add your own reviewer in `.ai-implement/config.yml` in your target repo. Each entry has these fields: * `id` — required * `prompt` — required * `model` — optional legacy model override; configured review-stage selection takes precedence ```yaml theme={null} reviewers: - id: security prompt: | Review the diff for injection, authentication, and secret-handling faults. model: claude-sonnet-5 ``` These rules decide which definition AI-Implement uses and whether it gates: | Case | Definition used | Effect | | - | - | - | | Selected in project settings, **Gates** on | The definition on the **default branch** | Gates the merge | | Same, and the pull request changes the definition | The default-branch version gates; the pull-request version also runs, labelled `{id} (branch advisory)` | Preview only; does not gate | | Same, and the definitions are identical | Runs once | Gates | | Selected, **Gates** off | The definition on the pull-request branch | Advisory | | Defined on the branch, not selected | The definition on the pull-request branch | Advisory | | Selected and gating, but missing from the default branch or unreadable | None | Review fails closed: `Selected reviewer(s) did not resolve from trusted code or default-branch config definitions: {ids}. Automated review is incomplete.` | A pull request cannot rewrite the reviewer that judges it. To add a gating reviewer: **1. Merge the definition to the default branch** Merge the reviewer's definition in `.ai-implement/config.yml` to the default branch. **2. Select the reviewer** Select the reviewer in the project settings. **3. Turn on Gates** Turn on **Gates** for the reviewer. The ids `claude-review-summary` and `legacy-post-push-review` are reserved. AI-Implement ignores a config entry whose id matches a built-in reviewer or an image-baked reviewer. ## Reviewers with code A fork of AI-Implement can add a reviewer that runs code. The fork bakes the reviewer module into the runner image at `custom/reviewers/.ts`. A reviewer with code overrides a built-in reviewer that has the same id. A target repository cannot supply reviewer code. See [Runner image](https://docs.builddown.ai/latest/customize/runner-image.md) and [Customize pipeline behavior](https://docs.builddown.ai/latest/customize/custom-steps.md). ## Turn limit These turn limits apply to Claude reviewers. AI-Implement takes the limit from the first of these that is set: * the reviewer's **Max turns** in the project settings * the built-in default * **Review Max Turns** in **Settings → Retry Policy** (default 30) When a reviewer reaches its turn limit, the review is incomplete and reports `REVIEWER_TURNS_EXHAUSTED`. See [A reviewer reached its turn limit](https://docs.builddown.ai/latest/reference/run-statuses.md#a-reviewer-reached-its-turn-limit). Codex reviewers use the configured review stage's elapsed timeout. **Max turns** and **Review Max Turns** do not cap Codex. See [Timeouts and limits](https://docs.builddown.ai/latest/configuration/agents.md#timeouts-and-limits). ## What the reviewer returns Each reviewer posts a report on the pull request. The report starts with the reviewer's label and one result: * `approved` — the reviewer found no problem * a finding count — the number of problems the reviewer found * `incomplete; no approval` — the reviewer did not reach a verdict After the result, the report shows a `Checks:` list. Each check has one of these results: * Passed * Failed * Not verified * Not applicable A reviewer that does not finish shows `{label}: review incomplete (required)` or `{label}: review incomplete (advisory)`. ### Source inspection and executed checks Codex review has restricted read-only access to repository text. It can read and search, but cannot edit files or run tests and shell commands. Read each check's evidence. A source inspection can support a check without executing a test. **Not verified** means the check was not established; it is not a test pass. Automated verdicts do not provide a required human GitHub approval. See [Approval is a comment](https://docs.builddown.ai/latest/reference/post-push-review.md#approval-is-a-comment-not-an-approving-review). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.