Set up managed reviews and project memory

Redgold's managed review offer helps small teams configure and operate pull-request reviews with useful project context. Access is invite-only during preview. Start with one repository, an agreed review workflow, and written pricing before enabling paid use.

Request a setup

Use the managed review request form. Describe the project, approximate pull-request volume, and the work you want to improve. A project description is sufficient; do not upload private code or credentials to the request form. Optional budget ranges help the onboarding discussion and are not service prices.

The form saves the request only after you agree to contact about access and onboarding. A receipt confirms that the request was saved. It does not create an active workspace, activate repository automation, or charge you.

Agree these items before purchasing:

• the repositories, supported languages, and review behavior included;
• setup work, ongoing operating help, and who handles an incomplete run;
• the subscription, any setup fee, included usage, and additional usage rates;
• separately billed model providers, compute, and other connected services;
• the first completed review used to evaluate the pilot;
• cancellation and the handling of retained project data.

Workspace prices are the published subscription plans. A workspace price alone is not a quote for every managed service or unlimited model and compute usage.

Connect the repository

In Settings → GitHub account, install or connect the Redgold GitHub App and select only the intended repositories. Redgold confirms the repository's workspace binding and enabled automation during onboarding. App installation alone does not activate review processing.

Open the repository's Review settings and agree the initial policy:

Begin with fixer commits off while assessing review findings. Keep the repository's existing CI, branch protection, and maintainer merge policy. A review or an eligible correction is not permission to merge automatically.

Spending limits stop future model calls after charged usage reaches the configured limit. Calls already in flight can overshoot, and configuration or usage can take up to 30 seconds to propagate. These controls are not a prepaid guarantee or a cap on the complete invoice. Review the actual billing terms and any direct provider charges as well.

Prepare project context

Keep current contribution rules, important constraints, and test commands in the repository. Include the reason and source for a decision so a reviewer can check whether it still applies.

For supported conversation history, open Settings → AI accounts & history → Import conversation history. Choose the appropriate .claude or .codex folder and review the files selected for import. This is a selected-file import, not continuous synchronization with your device.

Use Check indexed history to inspect readiness after an import. Use the separate Search workspace history form to find retained context. Open a result's source to confirm that it belongs to the intended workspace and is useful to the project. A saved upload, an indexed record, and a retrieved source in a review are separate outcomes; confirm the one you need instead of inferring it from another.

During onboarding, agree what is retained and how to inspect, correct, or remove it. Saved history does not mean every conversation is included in every review or that a private model is trained on it. See the project-memory guide.

Inspect the first completed review

Choose a small pull request where the intended behavior and relevant project constraint are clear. Record its commit and the selected review policy.

1. Confirm that the run belongs to the intended repository and workspace.
2. Inspect its activity, outcome, and charged usage. Identify stopped, failed, and incomplete stages separately from completed review findings.
3. Confirm that the posted review refers to the intended commit.
4. Open relevant conversation or context source links. Distinguish no matching history from unavailable or failed retrieval.
5. Have a maintainer assess which findings are useful and which need correction.
6. Run the repository's normal checks and merge only under its existing policy.

The pilot succeeds when your team can inspect a completed review and decide whether its findings, cost, waiting time, and operating effort are worthwhile. A completed model response alone does not establish review accuracy or savings.

Resolve common problems

Keep the run reference and commit when requesting operating help. Never paste tokens into public GitHub comments. For integration details, see Connect GitHub review automation. For a real workflow account and its limits, see Elusive managed reviews.