“Improve this page” leaves a lot of decisions open. Layout, copy, interactions, dependencies. Codex can suggest something coherent and still miss what you actually wanted.
Before asking it to write code, I prefer to make the expected result concrete enough to check.
Describe the outcome
For a newsletter form, “add error handling” is still vague. What does someone see when the service does not respond? Does their email stay in the field? Can they try again?
Those questions lead to a much more useful instruction.
In the newsletter form, show a message if subscribing fails.
Keep the entered address and allow a retry.
Prevent a second submission while sending.
Keep the current layout and dependencies.
Start by reading the component and server route.
Check success, network errors and a double click.
Do not send real emails, commit or deploy.
The prompt describes behaviour you can observe. You can open the page, trigger an error and check the result. It also says what should stay in place and what is not allowed.
Provide the missing context
A file path, a screenshot and an existing example can remove a lot of guesswork. If another page already has the right form, point to it. If an image should come from the project, give its location.
Rules that apply to every task belong in an AGENTS.md file: verification commands, repository conventions and operations to avoid. Details specific to a change belong in the request.
I also keep secrets out of prompts. Variable names and expected behaviour are usually enough to explain an integration.
Review the change
In a Git repository, these commands are a starting point for review. The pnpm scripts are the ones used by this portfolio. Adapt them to your project. They do not create a commit or send anything to the remote repository.
git status --short
git diff --stat
git diff
pnpm build
pnpm typecheck
pnpm test
git diff does not show the contents of new untracked files. The first command helps you spot them so you can open them separately. And a repository script is still code you should review before running it.
A “done” message is not proof. Look at the changed files, understand any new dependencies and try the cases that might fail.
Passing tests tell you something useful, but they do not tell you whether text overflows on mobile or a button is hard to find. For an interface, I also want to see and use the page.
When a task becomes hard to review, I prefer to split it up. Fix an error state, then check it. Add an interaction, then check it. Each step leaves a decision you can still understand and revisit.