Codex prompting
How I Brief Codex Now: Scope, Files, Boundaries, and Acceptance
I am not looking for one magic prompt. The reliable artifact is a short task brief: the outcome, where to start, what must stay untouched, and what evidence proves completion.
- Observed
- Explicit protected scope and acceptance commands reduce unrelated refactors and follow-up clarification in my work.
- Verified
- OpenAI Codex guidance covers tool use, persistence, verification, and output control; repository AGENTS.md files are suited to durable repeated rules.
- Limit
- A template cannot replace product judgment. Root-cause investigations still need room to explore.
Key takeaways
- State an outcome instead of a vague activity.
- Name entry files and protected boundaries to reduce unbounded exploration.
- Turn “done” into commands and observable behavior.
The five-line task brief
- 01Outcome
- 02Context
- 03Boundaries
- 04Acceptance
- 05Rhythm
Keep one primary outcome
“Improve this project” forces the agent to invent priorities. I rewrite it as a deliverable, such as “statically generate five localized blog editions and include them in the sitemap.” Metadata, schema, and internal links support that same outcome; a separate product feature does not belong.
For large work, I approve a specification or plan first. Exploration happens during design, while implementation follows one agreed boundary.
Give an entry point and a protected zone
Name likely files, existing helpers, and the framework that must remain so the agent starts in the right place. Also state boundaries: no deployment, no unrelated app changes, no restoration of retired capabilities.
Entry files do not prevent dependency searches. Protected zones should name an environment, path, or action. “Do not change things randomly” is too vague to verify.
Rewrite completion as evidence
“Done” should become tests, build results, visible behavior, and external-action boundaries: zero failures, build exit zero, no 390px overflow, one H1, and no production deployment.
I also state the test rhythm: run targeted checks needed for implementation risk, then run the complete suite, build, and browser acceptance after all related work is finished. This preserves early feedback without repeating full logs mechanically.
The five-line brief I reuse
These five fields cover most coding tasks. It is a checklist, not text that must be copied verbatim. If one is absent, I ask whether that absence could change the implementation direction.
- Outcome: what the user or system receives.
- Context: relevant paths, rules, and approved design.
- Boundaries: protected files and forbidden external actions.
- Acceptance: commands and observable page behavior.
- Rhythm: when to explore, implement, and run full verification.
How I think about prompts
A good brief does not ask the model to think less. It concentrates reasoning on the genuinely unknown parts and removes tool calls spent in the wrong direction.