Codex and Claude Code
Brief the behaviour. Verify the change.
Write clearer coding-agent prompts for bug fixes, feature work, refactoring and code review, with explicit scope and useful verification.
Updated
Describe a reproducible failure
An agent needs the trigger, observed behaviour and expected behaviour. ‘The form is broken’ could mean a network failure, validation issue, lost input or inaccessible control. Include exact errors, relevant versions and the smallest steps that reproduce the problem.
Ask it to inspect the existing project conventions before proposing a change. The smallest useful patch is often safer to review than a broad rewrite whose relationship to the bug is unclear.
In this repository, submitting [form] with [input] produces [observed result]. It should [expected result]. Reproduce the failure, identify the cause, implement a focused fix and verify the original case plus the nearest regression risk. Preserve unrelated changes and summarise remaining uncertainty.
Specify behaviour before implementation
For a feature, explain what the user can do and what happens when data is missing or invalid. Name compatibility constraints and the existing parts the agent should reuse. Choose implementation details only when they are actual requirements.
Add [feature] for [user] in this app. The successful flow is [flow]. Empty, loading and error states should [behaviour]. Reuse [existing component or pattern]. Implement the smallest complete version and verify keyboard access, validation and the saved result.
Review for consequential problems
A review prompt should name the risk. A payment change needs attention to duplicate requests and state consistency; a content change needs attention to links and indexing. Ask for specific findings with a trigger and impact rather than a generic list of suggestions.
Review this diff for bugs introduced by the change. Focus on [risk]. For each finding provide the trigger, affected behaviour, location and evidence. Separate confirmed defects from questions needing more context. Do not implement fixes during the review.
Define what verification means
A passing build does not prove a user flow works. Choose checks that would fail on the original problem. For a layout, inspect the rendered result. For data logic, exercise the boundary case. Ask the agent to report what it actually ran and what remains unchecked.
- Bug fix: original failing case and an adjacent regression case.
- Feature: successful path, error recovery and persistence.
- Refactor: preserved observable behaviour.
- Migration: representative inputs, compatibility and rollback considerations.
Before and after: acceptance criteria a coding agent can verify
Weak prompt: ‘Fix the contact form and make it better.’ This leaves both the defect and the permitted changes open. A visual redesign might look convincing while the original submission failure remains.
The stronger illustrative brief gives a reproducible case and observable acceptance criteria without dictating an unverified root cause. Adapt the trigger to your real bug. A diagnosis-only request should explicitly forbid implementation; the example below authorises a focused fix but not a deployment.
- Regression check: would the new test fail on the original version, and does it pass after the fix?
- Scope check: does each changed file contribute to the requested behaviour?
- Evidence check: distinguish a passing build, an automated behavioural test and an observed browser flow; none should be reported as another.
Fix this contact-form bug in the repository. Reproduction: enter a valid name, email and message, submit, and simulate a failed server request. Observed: the form clears the message and displays no useful error. Expected: preserve the input, show an accessible error and allow a retry. Inspect project instructions, relevant framework documentation and existing form conventions first. Reproduce the failure, explain the cause, then implement a focused fix. Acceptance criteria: a successful submission shows confirmation; a failed submission preserves all fields and exposes the error to assistive technology; a retry can succeed; invalid input does not submit; pending submissions prevent duplicate client requests and restore the control after failure. Check the server's handling separately before claiming duplicate processing is impossible. Add or update regression tests using existing tools, and inspect the rendered keyboard and error flow where possible. Preserve unrelated changes. Do not redesign the page, add dependencies or deploy. Report the exact checks run, their outcomes and anything you could not verify.
Common questions
Should I tell Codex or Claude Code exactly which files to edit?
Name them when you know the scope, but allow inspection of related code. Describe the required behaviour so the agent can detect when the apparent target is only a symptom.
Keep exploring
Sources and editorial note
Guidance checked 9 October 2026. These AI-assisted guides and original templates are reviewed against the linked sources. Results depend on your inputs and available tools. Model recommendations are editorial starting points, not comparative test results.