Define the review target
A good review request names the diff, branch, PR, or files to inspect. It should also state the expected behavior and any risky areas. Without that frame, a review can drift into style commentary.
Ask Codex to lead with findings. Each finding should cite a file and explain why the behavior can fail. A review comment without a failure mode is usually lower value.
Check behavior, not just syntax
Review should follow data flow and control flow. If a value enters through a route, changes in a component, and is saved through an API, Codex should inspect the full path before claiming the behavior is safe.
Useful questions include: what happens for empty input, missing permissions, slow network, duplicate submission, stale cache, failed migration, or partial deployment?
- Look for regressions in existing workflows.
- Look for missing negative tests.
- Look for unhandled loading and error states.
Keep review output small
A focused review should not list every possible improvement. It should rank findings by severity and include open questions separately from confirmed defects.
If no issue is found, the review should say that clearly and list residual risk, such as unrun tests or areas not inspected.