Terms in this guide: Acceptance criteria · Context
A project brief prevents the first turn from becoming a guessing exercise. It is especially useful for work that spans several files or depends on product decisions that are not obvious from the repository.
Copy this structure
Replace the bracketed text with concrete details. Delete sections that do not apply rather than filling them with vague language.
# Outcome
[Describe the finished behavior.]
# Context
[Explain the user need and relevant code area.]
# Constraints
[List compatibility, scope, and design constraints.]
# Validation
[List the commands and manual checks that must pass.]
# Deliverable
[State what should be changed and reported.]Add evidence close to the claim
Link an issue, screenshot, failing test, or log line when it establishes the current behavior. Name a reference implementation when matching it is part of the goal.
Keep implementation choices open
Describe the behavior and constraints more precisely than the mechanism. When the repository supports several sound approaches, ask Codex to compare them against the acceptance criteria before choosing.
Official references
Continue with a practical next step
Progress stays in this browser. No account needed.
Updates and upgrade guidance
- Learning context added
Added prerequisites, a suggested practice estimate, expected output, and connected definitions. The article procedure was not independently re-evaluated in this change.
What to do: Use the opening checklist to prepare. No software update is required for this editorial change.
This log starts with the first recorded review; it is not a reconstruction of earlier revisions.