Anatomy of a strong request
- Goal: which user-visible behavior must change.
- Context: where it happens and which existing pattern to follow.
- Boundaries: files, compatibility, security, and areas to leave untouched.
- Verification: expected tests, build, and visual checks.
Add title search to the catalog. Reuse the current styling and data. Do not add dependencies or change URLs. Include an empty state, keyboard navigation, and a test. Run lint, tests, and build; summarize modified files.
Edge cases in the request
If you do not name edge cases, the agent tends to optimize the happy path. Add two or three relevant edges: empty data, permissions, mobile, network errors, language, accessibility, concurrency, or migrations.
Required edge cases: - empty catalog: show a clear state - search with accents and uppercase: must find results - narrow mobile: input must not cover cards - during JavaScript loading: basic navigation must not break
Split work by risk
A small task can be implemented directly. For migrations or cross-cutting changes, request analysis and a plan first, review the decisions, and then authorize implementation.
Correct course precisely
Avoid “I do not like it.” State observed behavior, expected behavior, and a project reference: “The filter resets scroll; preserve position as the favorites list does.”
Definition of done
A convincing response is not enough. Work is done when the change is scoped, checks pass, and Codex explains any risk or verification it could not complete.
Lesson deliverable
What you will build
Practical evidence for "Request changes that can be verified" applied to a real or training repository.
Why it matters
The goal is to turn the lesson into a verifiable action, not just reading.
Starter repository or files
A small Git repository with Git, README, and one known validation command.
Steps
- 1. Inspect Git status before starting.
- 2. Ask Codex to work with limited scope.
- 3. Run the verification command.
- 4. Review the diff or produced evidence.
- 5. Record what is verified and what remains open.
Copy-ready Codex request
Apply the lesson "Request changes that can be verified" in this repository. Work in small changes, cite concrete files, run one verification, and finish with evidence and risks.
Expected result
A reviewable output: map, plan, diff, test, or report depending on the lesson.
Verification command
git status --short && git diff --stat
Manual check
Check that the result matches the requested scope and Codex did not touch unrelated files.
Mini exercise
Repeat the practice in another folder of the same repository, changing only one constraint.
Show solution
Keep the same goal, add one explicit constraint, and compare whether the final evidence improves.
Evidence to save
Save the prompt, commands run, relevant output, and git diff --stat.