Give reviewers a commit message that answers three questions: what changed, why it changed, and what deserves attention. Treat Codex as your drafting partner, not your source of truth. This walkthrough turns a staged patch into a concise explanation, with a human checkpoint before anything becomes permanent.
1. Stage One Change You Can Explain
Start by choosing the boundary of the commit. Keep a retry fix separate from an unrelated formatting cleanup. Use git add -p when you need to stage selected hunks rather than an entire modified file. Git supports this partial-staging workflow directly. ([git-scm.com](https://git-scm.com/docs/git-add/?utm_source=openai))
Apply a simple editorial test: can you describe the change without joining unrelated ideas with “and”? If not, consider splitting it. Ask Codex to describe the patch, but keep staging decisions under your control.
2. Make the Staged Diff the Evidence
Inspect git diff --cached before requesting a message. This command shows staged changes relative to HEAD by default: the patch prepared for the next commit, rather than every edit in your working directory. ([git-scm.com](https://git-scm.com/docs/git-diff?utm_source=openai))
Tell Codex: “Draft a commit message from the staged diff only. You may inspect surrounding code for context, but do not describe unstaged changes as included. Do not modify files, stage changes, or commit.”
Before sharing context, check for credentials, customer data, and internal material that your organization does not permit sending to an external service.
3. Supply the Reason the Diff Cannot Prove
Provide the decision behind the implementation. For example: “An expired session must stop the retry loop because another attempt cannot restore authorization. Preserve retries for transient network failures.” Treat this as an illustrative scenario, not wording to reuse regardless of your patch.
Keep the task, boundaries, and expected output explicit when prompting Codex; OpenAI’s prompting guidance discusses giving the agent clear instructions and context. ([developers.openai.com](https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))
Separate supplied intent from verified evidence. Add: “If the patch does not support my explanation, flag the mismatch instead of smoothing it over.” Do not ask the model to invent a business justification.
4. Request a Subject and a Selective Body
Use a focused drafting prompt: “Return one imperative subject naming the behavior change. Add a short body only where it explains motivation, compatibility, or a meaningful limitation. Avoid file inventories and unsupported claims.”
For the hypothetical retry patch, a candidate subject is “Stop retrying requests after session expiration.” A useful body might explain why expired credentials are terminal while network failures remain retryable. Accept that wording only if both statements match the implementation.
Reject phrases such as “improve robustness” unless the message identifies the failure being prevented. Follow your repository’s established prefix convention rather than introducing a new one.
5. Audit Every Claim Before Accepting It
Ask Codex to map each factual sentence to the patch or your supplied context. Delete claims about performance, security, compatibility, or test results that lack evidence.
- Behavior: Does the subject describe what changes for a caller or user?
- Scope: Does the message cover only this commit?
- Validation: Were the stated checks actually executed?
- Limits: Are important exceptions stated without speculation?
Keep message checking separate from code checking. Codex provides a code-review workflow for examining changes; use that when you also want findings about the patch itself. A polished explanation is not a substitute for reviewing the implementation. ([learn.chatgpt.com](https://learn.chatgpt.com/docs/code-review?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))
6. Save Your Commit-Writing Rules
Once the workflow works, place durable repository guidance in AGENTS.md, which Codex uses for project instructions. Keep the rules specific enough to check. ([learn.chatgpt.com](https://learn.chatgpt.com/docs/agent-configuration/agents-md?utm_source=openai))
Suggested guidance: “Draft from staged changes. Explain intent without inventing it. Never claim unexecuted tests passed. Do not commit without explicit approval.” Review the resulting message yourself before creating the commit.
7. Keep the Relay Choice Separate From Editorial Judgment
If you want a pay-as-you-go relay for this workflow, SwiftRelay works with Codex and bills per token. Sign up for SwiftRelay to try the process with the small gift credit available to new accounts.
Keep the same acceptance standard whichever setup you use: one identifiable change, an evidenced explanation, and no invented validation. Before committing, ask whether the message tells a reviewer something useful beyond what the diff already shows. If it does not, revise it—or shorten it.