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 completes by opening a pull request on its own branch, against your base branch. It does not merge automatically. That decision remains yours.

What comes with it

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

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

What to actually check

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

  1. Does it solve the right problem? Compare it against the acceptance criteria set out in the specification, not against your recollection of what you asked for.
  2. Does it fit the codebase? Conventions, naming, the structure of the abstraction. Coroid reads your code to infer these, and generally gets them right — but not always.
  3. What does it affect that you did not expect? Look at the file list before viewing the diff.
  4. Are the new tests meaningful? A passing test that asserts nothing is worse than having no test at all.

Sending work back

You have three options, ordered by increasing effort required:

  • Comment and request rework — the task goes back to the developer agent with your feedback, preserving its context. Ideal for cases where 'the work is correct but incomplete'.
  • Reject the plan and re-run — used when the approach is flawed, not the execution.
  • Cancel the task — when the work should not be done at all. Cancelling stops the run and frees up the agent slot.

Be specific in rework comments just as you would when speaking to a colleague. 'This does not handle the empty case in parseRange'produces a fix; 'needs work' leads to guesswork.

Merging

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

Nothing about merging is special — this is intentional. The pull request is a standard pull request, so it follows whatever review and CI processes you already rely on.

Next

Where to go next — links to the rest of the documentation based on what you want to do.