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 does not merge. That decision stays yours.

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.

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

Merge through your own provider, using your normal branch protection, required checks and approval rules. Coroid opens the pull request; your existing process governs what happens to it.

Nothing about merging is special — that is deliberate. The pull request is an ordinary one, so it flows through whatever review and CI you already trust.

Next

Where to go next — routes into the rest of the documentation by what you are trying to do.