Five prompts that make a Codex bug fix easier to verify

A Codex task can end with a convincing explanation while leaving the original
bug untested. The useful question at handoff is simple: what observation shows
that the reported behavior changed?

Here are five prompts you can adapt to an existing repository. They need no
extra skill installation. I maintain the open-source
Codex How To guide, where these
recipes live alongside longer engineering workflows.

The checkout scenario below is illustrative, not a benchmark result or a claim
that these prompts reduce token usage.

1. Define acceptance around observable behavior

Imagine an empty cart can reach payment. “Fix checkout” leaves room for a
cosmetic change that never addresses the payment call.

Try:

Fix empty-cart checkout. An empty cart must show the existing validation error
and must not call the payment client. Preserve the API response schema.
Run the relevant regression and repository-required checks. Report any
verification you cannot perform.

This makes two outcomes visible: the error and the absence of the payment
side effect. A test that checks only the error message covers half the contract.

2. Provide a lead, then let evidence guide exploration

Start at src/cart/checkout.ts and its callers. Inspect the existing payment
client tests for conventions. Expand your search when a dependency or call
path requires it.

Replace those example paths with real ones. A useful starting point can come
from a stack trace or a failing command. It should not become a rule that
prevents discovering the defect elsewhere.

3. Capture the failure before changing the implementation

Create the smallest regression that demonstrates this empty-cart failure.
Run it before editing the implementation. Then fix the cause and rerun the
same regression, followed by the required broader checks.

For this example, inspect whether the regression actually fails because the
payment client was called. An import error is not evidence of the checkout
bug. Likewise, a green pre-existing suite may simply lack this case.

Intermittent bugs need a different approach: instrumentation or a controlled
reproduction may be more useful than repeatedly rerunning a flaky test.

4. Review the candidate that will actually ship

Review the candidate diff for paths that still reach payment with an empty
cart, behavior changes for valid carts, and tests that pass for the wrong
reason. Give file evidence for consequential findings. After confirmed fixes,
rerun affected checks and identify the final reviewed revision.

For larger or riskier changes, a separate reviewer context can add coverage.
It also consumes resources and can miss defects. Keep review proportional to
the change; a second agent is not necessary for every edit.

5. Ask for a compact evidence handoff

Summarize the changed behavior, final revision, regression failure before the
fix, commands and results after the fix, review findings resolved, and anything
still unverified. Keep it short enough for another engineer to check.

A useful handoff distinguishes local tests from integration checks. For
example, a mocked payment client can establish that local code did not invoke
it; that alone does not verify a deployed payment service.

Try one change to your workflow

Use the reproduction prompt on your next bounded bug. Record whether it
reveals missing coverage or merely repeats what you already do. Compare
accepted outcomes and rework before interpreting time or token differences.

The full set of ten tips
also covers stalled retries, delegation, steering, and session handoffs.
The repository includes a disposable playground if you prefer a teaching
fixture over production code.

Which instruction has changed the outcome of a real task for you? A sanitized
example where one failed or added overhead is useful too.