Skip to main content
Extensions let Review read the ticket behind a pull request (PR) or merge request (MR): when the description links a Jira issue, a Confluence page, a Linear or Backlog issue, or a GitHub or GitLab issue, the reviewer fetches it and checks whether the code does what the ticket asks. Without an extension, Review judges the diff on its own and can’t tell you that an acceptance criterion was missed.

​
Available extensions

GitHub Issues appears only when your Review provider is GitHub, and GitLab Issues only when it’s GitLab. Not supported: Jira and Confluence Data Center or Server (the Atlassian connection works with Atlassian Cloud only), and Azure Boards, which has no extension. For those, paste the acceptance criteria into the PR description: Review reads the description along with the change.

​
Prerequisites

  • Review connected to at least one repository. See Review setup.
  • To connect a tracker: the workspace Admin role and access to More → Workspace settings → Connections. Other roles see View instead of Connect on tiles. See roles.
  • An account on the tracker that can read the projects your tickets live in.

​
Turn on an extension

1

Open the Extensions section

Go to Review → Settings and scroll to Extensions (“Link tickets and specs so Review can check changes against them”). Each tracker has a tile with its status.
2

Connect the tracker

Click Connect on the tile. CloudThinker opens More → Workspace settings → Connections with that connection’s form ready. Fill it in using the connection guide for Atlassian, Linear or Backlog, then save.Success state: back in Review → Settings → Extensions, the tile shows Connected.
3

Reference the ticket in the PR description

Put the ticket link or key in the PR or MR description. No command or setting is needed.Jira, Linear and Backlog keys look alike. With one of them connected, a bare key such as OPS-1234 goes to that tracker. With more than one connected, the reviewer has to try each, and a key that exists in two trackers can match the wrong ticket.
With more than one key-based tracker connected, always use full ticket URLs.
4

Open the PR and read the review

The review runs as usual. Findings now cover gaps against the ticket as well as the code itself.Success state: when the change misses part of the ticket, the review findings say which part.
Click Manage on a connected tile, or View on any other, to see what that extension reads and the patterns it recognizes. An extension is on whenever the workspace has that connection, including one first made for chat or another agent. It applies to every repository Review covers. There’s no separate switch or per-repository setting.
To stop Review reading a tracker, you have to disconnect it in More → Workspace settings → Connections. That removes the connection for every agent and chat in the workspace, not only Review.

​
Example

A PR description like this:
Say OPS-1234 lists “return 429 with a Retry-After header” as an acceptance criterion, and the diff returns 429 without the header. With the Jira extension, the reviewer has that criterion in front of it and can flag the missing header against the ticket, for example: “The login endpoint returns 429 without the Retry-After header that OPS-1234 requires.” Without it, the same diff looks correct. In the review workspace, a Ticket compliance card also rates the change Fully compliant, Partially compliant or Not compliant against the ticket. It works in any review mode. The card shows when exactly one Jira or Linear ticket was checked. With several tickets, or a Backlog ticket or Git issue, the review summary comment has a table instead, with one verdict per ticket.

​
What gets read

  • The description only. Review scans the PR or MR description for links and keys.
  • Not code. A key inside a code block or inline code (`OPS-1234`) is ignored, so example IDs in snippets don’t trigger lookups.
  • Up to 20 references per PR, taken from the first 65,535 characters of the description. Put the ticket that matters most first.
  • Tickets your connection can see. Review reads with the connected account’s access, so a ticket in a project that account can’t open isn’t available to the review.
  • Shown to your workspace. What the reviewer takes from a ticket can appear in findings. Those show in the review comments on the PR and to anyone with access to Review in the workspace. On a public repository, anyone who can see the PR can read those comments, so keep confidential detail out of tickets you link there. See data protection.

​
Write tickets that help the review

  • List acceptance criteria as separate lines. Each one becomes something the reviewer can check. “Works well” can’t be checked; “returns 429 after 5 failed attempts in 1 minute” can.
  • Link the spec, not just the ticket. A Confluence page with the API contract gives the reviewer the exact field names and status codes.
  • Reference every ticket the PR closes. A PR that fixes two bugs should name both.

​
Troubleshooting

Check: the reference is in the description, not only the branch name or commit message, and not inside backticks or a code block. Confirm the tile shows Connected.Fix: edit the description, then comment @cloudthinker-ai review on the PR so the review runs again and reads the new description. On AWS CodeCommit, push a new commit to the PR’s source branch instead. See mention commands.
Those tiles appear only for the matching Review provider. On Bitbucket, Azure DevOps or AWS CodeCommit, use Jira, Linear or Backlog instead.
Only workspace Admins can connect trackers. Ask a workspace Admin to connect it, or to change your role. See roles.
The connected account can’t open that ticket’s project. Grant it access in the tracker, or reconnect with an account that has it.

​
Next steps

Mention commands

Re-run a review after you update the PR description.

Learnings

Add your team’s coding conventions to every review.