Skip to main content
Learnings are reusable rules that CloudThinker derives from resolved Review findings — issues Review flagged that your team then fixed. They are separate from the convention files your team authors in the repository.

How it works

  1. Your team resolves findings in a repository’s review conversation.
  2. On the repository’s Learnings schedule, CloudThinker finds recurring patterns in those resolved findings.
  3. CloudThinker writes repository-scoped rules with their supporting citations.
  4. Review applies active Learnings to later merge requests and pull requests.
  5. Your team can inspect each rule and turn it off without deleting it.
Learnings need enough resolved findings to establish a recurring pattern. A new repository can remain empty after its first run when there is not yet enough evidence.

Set the update schedule

In Review → Settings, use the Learnings column for the repository. The first run starts soon after you enable a schedule. Later runs use the repository’s assigned Saturday window. The Learnings column shows the next scheduled run. Select Run now to request an immediate refresh. Scheduling becomes available after Review is enabled, the repository finishes cloning, and you have permission to manage Learnings.

Review learned rules

Open Review → Learnings to search and filter the rules CloudThinker derived. Filter by rule text, repository, or active status. Turn off a rule when you do not want Review to apply it, and turn it on again later without losing its evidence.

Read the evidence

Select a rule to open its description, guidance, examples, category, identifier, and citation count. The citation count helps you identify repeated review problems. Use the detail to decide whether to keep the Learning active or fix the pattern at its source.

Repository convention files

Repository-authored convention files are not Learnings. CloudThinker reads the guideline files your team already keeps in the repository — with no setup — and applies them during reviews and whenever an agent works on the repository’s files. Recognized files include AGENTS.md, CLAUDE.md, GEMINI.md, CONVENTIONS.md, and the rule files of common coding assistants, such as .cursorrules and .cursor/rules/, .github/copilot-instructions.md, .windsurfrules, .clinerules, and similar rule directories. Convention files are scoped by directory. When a review or an agent touches a file, the convention files in that file’s own directory and each parent directory up to the repository root apply — so a guideline placed in a subdirectory governs only the code beneath it, while a root-level file governs everything.

Configure convention sources

To adjust what is read, open the repository’s Actions menu in Review → Settings and select Review convention sources. Choose the coding assistant your team uses, then add any custom repository-relative file or directory paths. Convention files apply immediately. They do not require resolved findings or a Learnings schedule, so you can use either source independently or use both together.

Permissions

Viewing Learnings and changing their schedule or active state use separate workspace permissions. With view-only access, you can inspect rules but cannot change schedules or switches.

FAQ

Confirm that Review is enabled, cloning has finished, and the schedule is Weekly or Monthly. The repository also needs enough resolved findings to establish a recurring pattern.
No. Repository convention sources and Learnings work independently. Use both when you want Review to combine authored standards with patterns learned from resolved findings.
Yes. Turn off its Active switch. Review stops applying it, and you can turn it on again later.

Review

Understand the repository-level review workflow

Review setup

Enable repositories and configure their review behavior

Workspace Memory

See how agents remember context across conversations