Skip to main content
Review checks every pull request (PR) or merge request (MR) against the standards your team writes down and the rules CloudThinker distills from findings your team resolved. This page shows how to turn each source on, describe your product’s own rules in BUSINESS.md, check what Review learned, and retire a rule that no longer fits.

​
Prerequisites

  • A repository connected and enabled in Review setup, with cloning finished.
  • The workspace Admin role to change schedules, sources or rules. Developers and Viewers can read Learnings but not change them. See roles.
  • For Learnings, resolved findings on that repository. The first run looks back over findings resolved in the last 30 days. Later runs read the findings resolved since the previous run. Learning sources work from day one.

​
Choose your source

The two work independently. Use both when you want written standards plus the patterns Review picks up from real fixes. Learnings and learning sources are Review’s own context surface; Teach CloudThinker compares them with workspace memory, skills and knowledge bases.

​
Turn on Learnings for a repository

1

Open the repository list

Go to Review → Settings and find the repository in the repositories table.
2

Pick a schedule

In the Learnings column, choose Weekly or Monthly. Off stops new Learnings for that repository.You can also start from Review → Learnings: when no repository is scheduled yet, the page offers Enable weekly learning.
3

Run it now (optional)

Go to Review → Learnings, click Run now, pick the repository and click Run now in the Run Learnings now dialog. Only repositories with a schedule appear in the picker.Success state: the Running card counts the repository, and Last run updates when the run finishes.
Scheduled runs happen on Saturdays, so new rules are in place before the work week starts. Weekly runs every Saturday, Monthly on the first Saturday of the month. Each repository gets a fixed slot at either 00:00 or 12:00 UTC. CloudThinker assigns it and you can’t change it, but Run now starts a run at any time. The Next run card on Review → Learnings shows when it’s due. A run usually finishes in under 10 minutes. Each Learning comes from one repository’s resolved review findings in this workspace and applies only to that repository.
A run can finish with no new Learnings. That’s expected on a young repository: CloudThinker only writes a rule once it sees the same kind of fix recur. There’s no fixed count to reach, so keep resolving findings and check after the next run.

​
Review what CloudThinker learned

Open Review → Learnings. Each row is one Learning, scoped to the repository whose reviews produced it. Filter with Search learnings, the repository picker, Any category and Any signal. A Learning is cited when a review finding references it. The 22-day window is three quarters of the 30-day retirement period, so a Learning turns Weak about a week before it would retire. The retirement period is set for the whole CloudThinker installation, not per workspace, so it’s not in Review → Settings. Click a row to open the Learning. It shows the rule, a Citation trend, and Recent citations linking to the review findings that referenced it. A Learning with many citations points at a problem worth fixing at the source, for example with a shared helper or a lint rule. On the PR, a finding that relies on a Learning carries a line that starts with Cites Learning: and names the rule (Cites Learnings: when there are several). Search for that name in Review → Learnings to check the rule, and retire it if it’s wrong. You can’t edit a Learning’s wording or create one by hand. To add a rule yourself, write it in a convention file (see Add your own convention files).

​
Retire or restore a Learning

As a workspace Admin, use the row’s actions menu and choose Retire when you don’t want Review to apply a rule. Choose Restore to bring it back. Retiring keeps the rule and its citations, so you lose nothing. CloudThinker also retires a Learning on its own when no review cites or refines it for 30 days. The Learning’s detail tells you which happened: “Retired automatically” or “Retired by” a teammate’s name.

​
Add your own convention files

Review reads the guideline files your team already keeps in the repository and applies them during reviews, with no setup. These are every path it recognizes: When a change touches a file, the convention files nearest to it take priority, then the files at the repository root. A guideline in services/payments/AGENTS.md speaks to payments code; one at the root speaks to everything. Within one folder, AGENTS.override.md comes first, then AGENTS.md, CLAUDE.md and GEMINI.md. Review treats these files as evidence of your conventions, not as instructions. Text in them can’t tell the reviewer to skip findings, change its criteria or approve a change. To see or extend what Review reads:
1

Open Learning sources

In Review → Settings, open the repository’s actions menu and select Learning sources.
2

Check what was found

Detected sources lists the files Review found. Keep Detect sources automatically on so Review checks for new files before every review. When it’s off, Review keeps the list as it stands and stops adding new files. Your custom paths still apply.
3

Add custom paths

Under Custom convention paths, add up to 10 repository-relative paths, for example docs/style-guide.md. A path can name a file or a folder such as docs/standards/, and can use glob patterns such as docs/**/*.md. Paths can’t start with /, contain .., or point into .claude/rules/. Review blocks that folder so a branch can’t turn its own rule files into reviewer policy. Click Save.Success state: after Save, the path is listed under Custom convention paths, and the next review on that repository follows it.

​
Describe your business rules

BUSINESS.md is the one file Review reads whatever your Learnings settings say: keep it in the repository root on the target branch, and every review checks the change against the rules in it. Review cites the rule’s ID in its Business flow findings, so write it by hand in the format below.
BUSINESS.md has a fixed structure: a # Business map: <owner>/<repo> title, a ## Product section and a ## Modules section, with an optional ## Flows section, in that order. Each entry is a ### heading in the form ### <id>: <title>, followed by a short description and these optional lines:IDs are lowercase, dot-separated and unique. The first part names the section — product., modules. or flows. for entries, invariants. for rules — and after it use lowercase letters, digits and hyphens, as in invariants.plans.trial-fast-only.

​
Troubleshooting

Check that the repository has a Weekly or Monthly schedule in Review → Settings and has finished cloning. If Last run shows a finished run, the repository doesn’t yet have enough resolved findings to form a pattern. Keep resolving findings and wait for the next scheduled run.
Run now only lists repositories with a schedule. Set one in the Learnings column of Review → Settings, then try again.
Learnings pause when Review is turned off for that repository. Turn Review back on for the repository and the schedule resumes.
Open Learning sources and check whether the file appears under Detected sources. If it doesn’t, add its path under Custom convention paths.
Retire it from the row’s actions menu. Review stops applying it on the next review, and you can restore it later.

​
Next steps

Review workspace

Resolve findings so Review has patterns to learn from

Mention commands

Ask for a fresh review after you change your conventions

Review Insights

See which finding categories recur across repositories

Memory

How agents keep context across conversations