Review
Review Neroli coding-agent work with self-review summaries, diffs, checks, browser or simulator evidence, and a clear merge or archive decision.
Neroli lets you run a lot of work at once. Review is where that work turns into a decision.
You do not have to read every line cold. Ask the agent to review its own work first.
It should explain the change, check the diff, run the right automations, capture browser or simulator evidence when relevant, fix anything obvious, and leave you with a clean summary. Then you decide what lands.
One session
Move it to review
Put substantial work in In Review so it is visible as work awaiting a decision.
Steer before implementation
When an agent asks for plan review, command approval, or user input, answer inside the session so the context stays with the work.
Ask for self-review
Have the agent review its own branch before you do. It should summarize the change, list risks, inspect the diff, and run the workspace checks.
Let it clean up
If the agent finds obvious mistakes, missing tests, formatting issues, or docs gaps, let it fix them in the same session.
Read the result
Start from the agent’s review summary, then inspect the files that matter: product code, tests, migrations, scripts, config, docs, and generated artifacts.
Verify from the session
Use the same Build, Verify, browser, simulator, or terminal automations attached to that session.
Look at evidence
Use browser state, screenshots, simulator output, artifacts, generated docs, logs, and diffs as review evidence.
Decide
Move it to Merge, open a pull request, continue the session, manually edit, archive it, or mark it Done after validation.
A useful review prompt
Review your own work before I merge it.
Summarize what changed, inspect the diff for unrelated edits or risky files,
run the relevant checks, fix anything obvious, and tell me what still needs my
attention.Many sessions
Parallel sessions are where Neroli opens up. You can let several agents explore, then ask each one to review itself before you compare the results.
Common patterns:
- one session builds a feature while another updates docs
- several sessions explore different implementations
- one agent writes tests while another changes the product
- one cloud session keeps working while you continue locally
Ask each branch for a self-review first. Then compare the summaries, diffs, and verification results. Merge one, merge several in sequence, continue the best session, or combine work manually when that is the right call.
The sidebar board makes this easier: keep active work in In Progress, move large changes to In Review, use Merge for candidates that look ready, and keep Done for work you want visible before archiving it.
What good evidence looks like
| Work | Evidence to ask for |
|---|---|
| UI change | Browser or simulator screenshot, route tested, and visible behavior summary. |
| Backend change | Relevant test output, logs, migration notes, and failure mode summary. |
| Docs change | Rendered page check, broken-link result, and what changed for the reader. |
| Automation change | Run log, stop behavior if applicable, and when it should be used. |
| Cloud work | Handoff state, local verification after bring-back, and any recovery messages. |
Red flags
- the self-review is vague or skips the risky parts
- the diff is larger than expected
- tests were deleted instead of fixed
- verification ran from another session
- evidence is missing for a user-visible change
- cloud returned changes that were not checked locally
- conflict warnings show another session touched the same file or flow
Next: use Recipes and gotchas for parallel work, cloud handoff, and review checklists.