> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt > Use this file to discover all available pages before exploring further. # Learnings > Teach Review your team's standards from resolved findings and from the convention files already in your repository. 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. | Term | Who writes it | What it is | | - | - | - | | **Learnings** | CloudThinker | Rules distilled from review findings your team already resolved | | **Learning sources** | Your team | Convention files you keep in the repository, such as `AGENTS.md` | | **`BUSINESS.md`** | Your team | A map of your product's modules and the rules (invariants) they must keep | ## Prerequisites * A repository connected and enabled in [Review setup](https://docs.cloudthinker.io/guide/code-review/setup.md), 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](https://docs.cloudthinker.io/guide/security/roles.md). * 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 | | Learnings (CloudThinker writes) | Learning sources (you write) | | - | - | - | | Where the rules come from | Recurring patterns in findings your team resolved | Files your team writes, such as `AGENTS.md` or `.cursorrules` | | Setup | Turn on a Weekly or Monthly schedule per repository | None. Detected automatically | | When they apply | After a run finds enough evidence | On the next review | | Best for | Mistakes your team keeps fixing by hand | Standards you've already written down | 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](https://docs.cloudthinker.io/guide/teach-cloudthinker.md) 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. > [!NOTE] > > 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. | Column | What it shows | | - | - | | Learning | The rule in plain words, plus its short identifier | | Signal | How much recent reviews rely on it (see below) | | Category | Security, Performance, Patterns or Correctness | | Repository | The repository the rule applies to | | Created | When CloudThinker wrote the rule | Filter with **Search learnings**, the repository picker, **Any category** and **Any signal**. | Signal | Meaning | | - | - | | Strong | Cited often and recently by reviews in this repository | | Quiet | On, but cited less than Strong | | Weak | Not cited recently. It retires soon unless a review cites it | | Retired | Off. Reviews no longer use it | A Learning is cited when a review finding references it. A Learning that reviews stop citing turns Weak, then retires on its own, so your rules stay current. 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](#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: | Tool or scope | Files and folders | | - | - | | Any folder in the repository | `AGENTS.md`, `AGENTS.override.md`, `CLAUDE.md`, `GEMINI.md` | | Repository root | `CONVENTIONS.md`, `.rules` | | Cursor | `.cursorrules`, `.cursor/rules/*.mdc` | | GitHub Copilot | `.github/copilot-instructions.md`, `.github/instructions/**/*.instructions.md` | | Windsurf | `.windsurfrules`, `.windsurf/rules/**/*.md` | | Cline | `.clinerules`, `.clinerules/**/*.md` | | Roo | `.roorules`, `.roo/rules/**/*.md` | | Continue | `.continuerules`, `.continue/rules/*.md` | | Augment | `.augment-guidelines`, `.augment/rules/*.md` | | Junie | `.junie/AGENTS.md`, `.junie/guidelines.md`, `.junie/guidelines/` | | Amazon Q | `.amazonq/rules/*.md` | | Kiro | `.kiro/steering/` | | Trae | `.trae/rules/` | 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` describes your product's modules and the rules (invariants) they must keep, such as which plan unlocks which feature. Review reads it whatever your Learnings settings say: keep it in the repository root on the target branch, and every review checks the change against it. See [Business flow checks](https://docs.cloudthinker.io/guide/code-review/business-flow.md) for the file format, an example and troubleshooting. ## Troubleshooting > [accordion] Review → Learnings is empty > > 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. > [accordion] Run now shows No scheduled repositories > > **Run now** only lists repositories with a schedule. Set one in the **Learnings** column of **Review → Settings**, then try again. > [accordion] The schedule shows Paused while Review is off > > Learnings pause when Review is turned off for that repository. Turn Review back on for the repository and the schedule resumes. > [accordion] Review ignores a guideline file > > Open **Learning sources** and check whether the file appears under **Detected sources**. If it doesn't, add its path under **Custom convention paths**. > [accordion] A Learning is wrong for our codebase > > Retire it from the row's actions menu. Review stops applying it on the next review, and you can restore it later. ## Next steps > [card] [Review workspace](https://docs.cloudthinker.io/guide/code-review/review-workspace.md) > > Resolve findings so Review has patterns to learn from > [card] [Mention commands](https://docs.cloudthinker.io/guide/code-review/mention-commands.md) > > Ask for a fresh review after you change your conventions > [card] [Review Insights](https://docs.cloudthinker.io/guide/code-review/analytics.md) > > See which finding categories recur across repositories > [card] [Memory](https://docs.cloudthinker.io/guide/memory.md) > > How agents keep context across conversations This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.