Reviewing & approving fixes
When a card reaches the Review stage, the AI has opened a pull request in your repository and the work is in your hands. This is where you decide whether the fix ships.
Reviewing the pull request
Section titled “Reviewing the pull request”A Review card shows a link (or links) to the generated pull request. Open it in your version-control provider and review it the way you’d review any change — read the diff, check that CI passed, and confirm the fix is correct and complete. The board doesn’t replace your normal code review; it points you straight to it.
Approving
Section titled “Approving”Once you’re satisfied, approve the fix from the card. The approve action comes in two forms, depending on your organization’s guardrail policy:
- Approve — approve only. The card advances, but you merge the pull request yourself in your version-control provider.
- Approve & merge — approve and merge the pull request automatically.
The button wording always reflects your current policy, so you can tell at a glance which behavior you’ll get.
When the fix is approved (and merged, if your policy allows it), the card moves to Approved.
Handling merge conflicts and failures
Section titled “Handling merge conflicts and failures”If a merge can’t complete — for example, the branch has conflicts or the merge fails — the card stays in Review and shows an error. Resolve the conflict in your repository and retry, or reject the fix if it’s no longer wanted.
Rejecting a fix
Section titled “Rejecting a fix”On a Review or Blocked card, choose Reject. A reason is required. Rejecting closes any open pull requests for that card and moves it to the Rejected side state, leaving a record of why.
To change whether approving also merges, see Guardrails & policies.