Skip to main content
A pull request looks small, but it would break the running release the moment it deploys. This walkthrough shows Review catching it, how you check the finding, and how the fix lands before anyone merges.

​
The scenario

A developer opens a pull request that renames the orders.status column to orders.state and updates the new code to match. Tests pass. The version running in production still reads orders.status, so during the rollout every checkout on old pods would fail. The same pull request also adds an admin endpoint without the shared permission check your other handlers use.

​
Prerequisites

  • Review set up on the repository, with a connected Git provider such as GitHub, GitLab, or Bitbucket. See Set up Review.
  • Optional: a CONVENTIONS.md or AGENTS.md in the repository, so Review knows your team’s patterns. See What Review reads.

​
Walkthrough

1

Open the pull request

Open the pull request as usual, marked ready for review. Review skips drafts until they’re ready. Nobody needs to start it.What you should see: once the review finishes, a summary comment from @cloudthinker-ai on the pull request, plus inline comments on the lines it flags.
2

Read the findings

The migration gets a High finding in the deploy, migration, and backward compatibility category: the old release still reads orders.status. The new endpoint gets a Security finding for the missing permission check. Each finding carries a suggested fix.What you should see: the verdict Changes requested, because at least one Critical or High finding is unresolved. Your provider’s branch rules still decide whether the pull request can merge.
3

Open the review in CloudThinker

Go to Review → Reviews. The pull request sits on the Needs attention tab. Open it and read the Walkthrough on the Overview tab, then the cards on the Findings tab.
4

Question the riskiest finding

Reply in the migration finding’s thread on the pull request:
What you should see: a reply that names the files that still read the column and suggests a sequence, such as adding the new column first and dropping the old one in a later release.
5

Push back where the code is intentional

If a finding is wrong, reply in its thread with your reason. No mention is needed:
CloudThinker re-checks the finding against the code and your reply. It withdraws the finding, acknowledges it, or keeps it open and says why. See Push back on a finding.
6

Land the fix

On the finding card in CloudThinker, click Apply fix to commit the suggested change, or Copy prompt to hand it to your own coding agent. On GitHub or GitLab, to review the fixes in their own pull request first, comment:
Fix all findings in the review header commits every fix to the source branch at once. Your click is the approval: fix commits from Apply fix and Fix all findings don’t go through Approvals.
7

Push and get the re-review

Push your changes. Review reads only the new commits and checks whether the earlier findings were fixed.What you should see: fixed findings move to Resolved, and the verdict changes to Approved once nothing is left unresolved. The pull request moves to the Ready to merge tab.

​
What made this work

  • Review read beyond the diff. It compared the change with code the running release still uses, which tests on the new code alone can’t show. See What it checks.
  • Conventions set the bar. The shared permission check was a pattern your repository already follows, so a handler that skipped it stood out.
  • You could argue with it. Mention commands let you ask why, push back, and get a re-check in the same thread.
  • Votes shape later reviews. A thumbs-down with a note on a wrong finding keeps later reviews of the repository from raising it again on unchanged code. See Review workspace.

​
Next steps

Review workspace

Triage reviews, settle findings, and merge from CloudThinker.

Mention commands

Every @cloudthinker-ai command and where each provider supports it.

Learnings

Turn resolved findings into patterns that future reviews apply.