01 / Define the review scope
Choose the repository and the behavior the reviewer should check. Include contribution rules, test commands, and areas that require a maintainer’s judgment.
USE CASE · REPOSITORY REVIEW
Give every pull request a clear review workflow.
An AI reviewer is useful when it can explain what changed, identify a concrete problem, and show how to check it. Start with the repository’s own rules and keep review evidence attached to the change.
A review loop with visible evidence.
02 / Review the current change
Evaluate the pull-request diff and relevant surrounding code. A useful finding identifies the affected behavior, its trigger, and the evidence supporting the concern.
03 / Check and resolve
Run the repository’s required checks and review the result. If correction mode is enabled, evaluate the follow-up commit through the same process.
Worked example: a permission regression.
Imagine a support application where each customer can see only their own tickets. A pull request simplifies a query and accidentally removes the customer filter. The changed code can still return valid records and pass a basic page-load check.
A useful review explains that a request from customer A could now return customer B’s ticket. It points to the changed query and asks for a check using two customer identities. The reviewer should distinguish that reproducible concern from stylistic preferences or speculation.
| Review question | Evidence to inspect |
|---|---|
| What changed? | The ticket query no longer filters by the requesting customer. |
| How would it fail? | A customer requests the list while another customer has a stored ticket. |
| What checks the fix? | Each customer sees only their own records, including through direct API requests. |
Configure access and automation deliberately.
Redgold’s GitHub App connects a selected repository to a workspace. During managed preview, onboarding establishes that binding and the enabled automation modes. Installing the App alone does not activate review processing.
Begin with review-only behavior if you want findings without automated code changes. Optional fixer mode can produce a follow-up commit for an eligible finding. Branch protection, repository permissions, and required checks still determine what can proceed.
Decide what a successful review looks like.
An agent’s review can miss a bug or raise a mistaken concern. Use the evidence in each finding, the test results, and maintainer review to decide whether the change is ready.
- Findings refer to the current pull-request commit and explain an observable effect.
- The reviewer follows the repository’s instructions and records which checks ran.
- A suggested correction stays within the reviewed issue and can be inspected as a diff.
- A maintainer can accept, reject, or ask for clarification, with the normal merge policy retained.