CoroidYour AI software factory
Documentation

Review and merge the result

What arrives on the pull request, what to check, and how to send work back.

Coroid finishes by opening a pull request on its own branch, against your base branch. It never merges on its own. Merging is always a person's decision, made either in your provider or with Approve & merge in Coroid. See Merging.

What arrives with it

  • the code change
  • tests written or updated alongside it
  • the result of running your existing suite
  • the outcome of any quality gates your organization has configured
  • a review pass over the diff, with findings either already fixed or listed

The point is not to replace your review. It is that your review should not be the first one.

Add a --json flag to the export commandCoroid branchmain
  • The code change4 files
  • Tests written or updated2 files
  • Your existing test suitePassed
  • Quality gates1 advisory finding
  • Review pass2 fixed, 1 listed
Merges through your provider, under your branch protection.You merge
Illustrative pull request. The mechanical checks are done before you look, so your review can focus on whether it is the right change.

What to actually check

The mechanical things have been checked already. Spend your attention on the things only you can judge:

  1. Does it solve the right problem? Compare it against the specification's acceptance criteria, not against your memory of what you asked for.
  2. Does it fit the codebase? Conventions, naming, the shape of the abstraction. Coroid reads your code to infer these, and gets them mostly right — mostly is not always.
  3. What does it touch that you did not expect? Look at the file list before the diff.
  4. Are the new tests meaningful? A passing test that asserts nothing is worse than no test.

Sending work back

You have three options, in increasing cost:

  • Comment and request rework — the task goes back to the developer agent with your findings, keeping its context. Best for "this is right but incomplete".
  • Reject the plan and re-run — when the approach is wrong, not the execution.
  • Cancel the task — when the work should not happen at all. Cancelling stops the run and frees the agent slot.

Be specific in rework comments the way you would with a colleague. "This does not handle the empty case in parseRange" produces a fix; "needs work" produces a guess.

Merging

Coroid never merges on its own. There is no setting that makes it merge when a task finishes. A merge happens in one of two ways, and each starts with a person deciding to merge.

This holds for work started under a mandate too. Coroid records what it would have decided about each merge, to measure its own judgement, but never acts on that record. See What Coroid decides, and what stays with you.

In GitHub or GitLab

Merge the pull request in your provider, using your normal branch protection, required checks and approval rules. The pull request is an ordinary one — that is deliberate — so it goes through whatever review and CI you already trust.

From Coroid, with Approve & merge

The review screens in Coroid have an Approve & merge button. It asks you to confirm, then Coroid merges the pull request for you through GitHub or GitLab, using the project's repository connection. It is the same merge as pressing the merge button in your provider, so your branch protection, required checks and approval rules apply. If they block the merge, Coroid shows the provider's reason and nothing is merged.

What happens before the merge depends on what you are approving:

  • A task. The task needs a pull request first. If it has none yet, the review screen offers Create PR before Approve & merge. When you approve, Coroid pushes the task branch so the pull request has the latest reviewed commits, then merges the pull request. Approving a task requires write access to its project.
  • A plan. Tasks that belong to a plan cannot be merged one by one. The plan's single pull request is approved from its promotion review. Coroid first checks that the base branch has not changed since the plan started (see When the base branch moves), the required quality checks pass, the pull request has no merge conflicts, and no lane gate is blocking. It then merges the pull request. Approving a plan requires write access to its project.
  • Force merge. A plan's promotion review also offers Force merge. It skips Coroid's base-branch, merge-conflict and lane-gate checks, but not the required quality checks or your provider's rules. It needs a written reason, which is recorded with the promotion, and admin access to the project.

The chat assistant and MCP clients can approve or force-merge a plan's pull request too. They act as you, so the same checks and project access apply. The assistant always asks you to confirm first. A force merge from an MCP client always waits in Approvals for a person. Whether an approval from an MCP client waits there depends on your automation policies. Neither can merge a single task.

Prepare what will ship

After merging, open your project's Releases tab and choose New release. Pick the merged commit you want to ship; Coroid lists the pull requests it contains. The release page then walks each environment through four steps: checks, approval, deploy, and health. Your repository and CI/CD still do the deploying. Coroid marks a release deployed only when your pipeline confirms it, or when an Owner or Admin records a verified external deployment.

Next

Releases — prepare the merged commit and follow it through each environment. Where to go next lists the other workflows.