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.
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.