Skip to content
KurrentDB

Get a review before you merge

Have a second agent read your code with fresh eyes, then re-check after you fix what it found. A review flow does this in rounds until the reviewer has nothing left to say. It works on a branch, on a pull request already open, or on uncommitted work you describe. Ask from whichever coding agent you work in; the example has Gemini CLI asking and Codex reviewing

Gemini CLI asks for the flow, a Codex reviewer finds two things, Gemini CLI fixes them, round two is clean. Everything below stands on its own

You need a daemon running on a machine that has the reviewer’s CLI installed; your own laptop is fine. See Hosted agents if you have not started one

In your working agent:

Complete a Codex code review flow on our code

Any kcap-supported coding agent can be the reviewer: Claude Code, Codex, Cursor, Copilot CLI, Gemini CLI, Kiro, OpenCode, Pi, Antigravity, Muse Code or Grok Build, whichever the daemon has installed. Name the one you want in the prompt, as above; a reviewer from a different vendor than your working agent tends to find different things. Leave the model to the vendor’s default unless you have a reason

The reviewer reports findings with file and line. Your working agent addresses each one, commits, and submits the next round. The reviewer looks only at what changed since, so later rounds are fast

You can watch from the web UI under Flows: each round’s outcome, the reviewer’s session, and the cost so far

A round comes back clean when the reviewer has no findings left. Waiting or unclear means it needs a human look; failed means the reviewer did not finish and is not a sign-off

Now open the pull request, if it is not already open. The review flow’s run is linked from the session, so whoever reviews the PR can see what was already checked

A flow launches a reviewer on a daemon; the daemon’s owner may have a launch approval policy that prompts them or refuses strangers. Use your own daemon, or ask them to allow you. See Launch approvals

The reviewer works from the daemon’s checkout. If your changes are not committed, or live in a different checkout, say so; the agent can supply a diff instead, and the run’s How it ran section shows which workspace the reviewer actually used

  • Review: reviewing a pull request with the sessions behind it, from the terminal or the web UI
  • Flows: catalog and one-off flows, following a run, and writing a definition for your team