Check Codex work before you call it done

1. Describe an observable result

Before a task starts, replace 'fix the search page' with a scenario: 'A search with no matches shows an explanation and a working reset button.' That gives you something concrete to check when Codex finishes.

Keep the acceptance check proportionate. A spelling correction usually needs a diff and a page readback. A payment or account change needs the relevant test environment and a much stronger check of the resulting state. Decide that scope before execution.

2. Inspect the change you will keep

In the desktop app, use the review surface to inspect the changed files. In a terminal, use Git to inspect unstaged and staged changes separately. Check new files as well: ordinary git diff output does not include the contents of untracked files.

Look for unrelated edits, removed checks, unexpected dependencies, and settings changed merely to silence a failure. Ask why each file is part of the solution. Our review routine treats an unexplained change as unfinished work, even when a test suite is green.

git status --short
git diff
git diff --staged

Reference: OpenAI: Code review · Git: git diff

3. Test the behavior that matters

Ask Codex to identify the repository's existing check commands before running them. Start with the test closest to the changed behavior, then run the broader checks needed for the affected area. A command that did not run is not a passing result.

For the search example, try a matching query, a query with no matches, and resetting the query. If the UI changed, inspect a narrow viewport and keyboard access too. Build success can catch compilation problems, but it does not show whether a button is covered or the empty-state message is readable.

• Record the exact command, result, and any skipped check.
• After a repair, rerun the checks affected by that repair.
• For an external action, verify the target system's resulting state; a request being sent is only an intermediate result.

4. Name the delivery state precisely

A useful closeout says what changed, why, how it was checked, and what remains. It should also tell you where the work exists. Local files, a Git commit, a remote branch, and the live website are separate states.

For example: 'The empty state works locally and its interaction check passes. The change is committed on the feature branch; it has not been pushed or deployed.' You can then decide the next action without guessing what 'done' means.

Try it in Codex

Ask for an evidence-based review

Review the current task against its original requested behavior. Inspect the current Git diff, staged changes, and new files. Explain unrelated changes if any.

Identify and run the relevant existing local checks, avoiding commands that mutate production or external accounts. For UI changes, verify the real interaction if browser tools are available; otherwise mark that check as not run.

Report what passed, what failed, and what was not checked. Separate local completion, Git state, and production state. Do not edit application code, commit, push, merge, or deploy during this review.

Check your result

• Every changed file has a reason connected to the task.
• The original user scenario works in the stated environment.
• Skipped checks and remaining risks are visible.
• You know whether the change is local, committed, remote, or live.

Sources and scope

Official references support the product behavior described above. The task prompts and practical checks are our community guidance.

• OpenAI: Code reviewThe app's diff and review workflow.
• Git: git diffThe distinction between unstaged and staged diffs.

Something changed in your version? Send a correction with the guide URL, platform, and version. Leave out credentials and private project content.