Skip to main content
Review posts its findings on your merge requests and pull requests (MR/PRs) and keeps a copy of every review at Review → Reviews in CloudThinker. From there you can see what needs you, settle each finding, commit fixes, and on GitHub or GitLab merge, all in one place.

Prerequisites

  • At least one repository connected in Review setup, with one MR/PR reviewed.
  • A workspace role that fits what you want to do (see Roles):
Your provider’s branch protection and approval rules still apply to everything you do here. A push or merge your provider refuses fails in CloudThinker too.
These roles apply only inside CloudThinker. Comment commands on your provider follow its comment permissions instead: anyone who can comment can run @cloudthinker-ai autofix. See the autofix warning.

Triage the Reviews list

1

Open the list

Go to Review → Reviews. Every MR/PR that CloudThinker tracks sits in one of four tabs, each with a live count.
2

Narrow it down

Filter with Search title or number…, repository, author, or verdict. Use the density toggle to switch between Comfortable and Compact rows. Your filters stay applied when you switch tabs.Success state: the tab counts match your filters, and each row shows the title, author, repository, verdict, and how many findings are still unresolved.
A verdict is the review’s overall call on the MR/PR. A finding is one issue the review flagged for a human to look at. A red Conflict badge next to a title means your provider reports that the MR/PR can’t merge because its branches conflict. When CloudThinker has opened a fix for it, the row also links to the Resolution MR (or Resolution PR). See Auto-resolve conflicts.

Read a review

Click a row to open the review. The page has these tabs: Where to find CI runs depends on your provider: The rail beside the tabs shows the Review summary: the verdict, unresolved findings by severity and category, and any Learnings the review cited. Below it, Rate this review takes 1 to 5 stars. If an extension found a linked ticket, a Ticket compliance card rates the change Fully compliant, Partially compliant, or Not compliant against the ticket, with the agent’s notes.

Work the findings

1

Open a finding

On the Findings tab, expand a card. You see the severity, file and line, the agent’s explanation, the original code and suggested fix, and a chip for any Learning it relied on.
2

Vote on accuracy

Click thumbs-up if the finding is right. Click thumbs-down if it’s wrong, and describe what it got wrong in the Inaccurate finding note. Notes are kept per repository: later reviews of that repository get its newest 20 notes from the last 90 days, so they don’t raise the same issue again on unchanged code. This is separate from Learnings.
3

Fix it

Pick the path that fits:Apply fix fails when your provider won’t let the connected identity push to the source branch, for example a protected branch or an MR/PR opened from a fork. The card then says This branch can’t be updated automatically. Use Copy prompt there. On GitLab, a Maintainer token can push to protected branches (see provider authentication).Apply fix isn’t available on Bitbucket, but Fix all findings is.
4

Settle it

Click Mark resolved once it’s handled, or Reopen to undo. On GitHub, GitLab, Bitbucket, and Azure DevOps, resolving also resolves the finding’s comment thread on the provider. On AWS CodeCommit the finding settles in CloudThinker only.Success state: the card moves to the Resolved group, and the unresolved count on the Reviews list drops.

Ask about the whole review

Click Ask CloudThinker in the header. A chat drawer opens beside the review, scoped to this MR/PR and separate from the agent’s own review run. Try:
The drawer keeps the repository and any finding you asked from as locked context, so answers stay on this review. Each question uses credits like any chat message.

Re-run, fix, and merge

Header buttons cover the actions that change the MR/PR. Less frequent ones sit in the More actions (⋯) menu.
Merge needs your own linked GitHub or GitLab account. CloudThinker asks you to link it the first time you click Merge, or you can do it ahead of time in Account Settings → Linked accounts: click Link GitHub account or Link GitLab account. A GitLab link asks for the api scope; a GitHub link is a GitHub App user authorization.
When you click Merge, pick a merge method (Create a merge commit, Squash and merge, or Rebase and merge, as your repository allows) and choose whether to Delete source branch. If the review requested changes, a review is still running, or the newest commits aren’t reviewed yet, a Check before you merge warning appears and the button reads Merge anyway.
Fix all findings pushes commits to the source branch without a separate approval step. On GitHub or GitLab, comment @cloudthinker-ai autofix stacked instead to get the fixes in their own MR/PR first.

Troubleshooting

Cause: the code changed after the review, so the original lines are gone or appear more than once, or the source branch is protected or in a fork. Fix: re-run the review to get a fix against the current code, or apply the change through your Git provider.
Cause: your workspace role is Viewer. Fix: ask a workspace Admin for the Developer role.
Cause: the MR/PR has no unresolved findings left to fix, or the repository is on AWS CodeCommit, which doesn’t support it. Fix: check the Findings tab to confirm everything is resolved. On CodeCommit, use Copy prompt on each finding.
Check: the reason under the menu item. A running review must finish or be stopped first. Merged MR/PRs keep the item visible but disabled.
Check: the All tab with filters cleared. If it’s still missing, confirm the repository is enabled and the webhook is set up in Review setup. Draft MR/PRs aren’t reviewed.

Next steps

Mention commands

Run the same actions from MR/PR comments on your provider.

Learnings

Turn your team’s settled findings into repository rules.