Prompt formula
- Goal: what you want completed.
- Scope: where it lives and what area matters.
- Constraints: safety rules, style rules, and do-not-touch rules.
- Done means: what output you want back from Codex.
Codex works best when you use it like a careful technical teammate: give it the outcome, give it the local context, say what is risky, and ask it to verify the result. This page turns that idea into a practical guide you can reread while you learn.
The shortest useful mental model is: ask clearly, constrain risk, review the work, and close the loop with verification.
Most weak results come from requests that are too vague. You get better work when every request names the goal, scope, constraints, and definition of done.
Best default sentence: “I’m new to this. Keep it safe, show the preview first, and explain the best practice while you do it.”
Fix the signup bug in this workspace. The problem is that the submit button does nothing on mobile. Only change the signup flow files and do not touch styling outside that flow. Run the relevant check and tell me exactly what changed.
Understanding the internal rhythm helps you collaborate better. Codex will usually inspect the workspace first, decide on a path, make changes, and then verify what it did.
This is one of the most useful distinctions for a beginner. Start with preview when there is risk. Use execution when the task is bounded and you are ready for the change.
Use this when you want a safe proposal first.
Use this when the task is clear and you want real action.
A lot of beginners underuse Codex by asking only broad questions. It is usually better at concrete tasks with a visible output.
Codex becomes much safer when you tell it exactly what it must not do. These lines are short, but they prevent a lot of mistakes.
The issue is usually not that Codex cannot do the task. The issue is that the request does not create a clear target or safe boundary.
“Check this repo.”
Too open-ended. There is no finish line and no clue what matters.
“Find why login fails, fix only the login flow, run the relevant check, and summarize the change.”
Clear goal, clear scope, clear verification.
If you want to get good quickly, do not jump straight into high-risk automation. Build your habits in stages.
These are written to be practical. Replace the nouns and keep the structure.
Read this folder and explain how it works in plain English. Focus on the main files, the data flow, and what I should read next. Do not edit anything.
Find why this feature is failing, fix only the relevant files, and verify the result. Do not rewrite unrelated code. Tell me exactly what changed and what check you ran.
Read the recent context for this lead and draft the next reply in my tone. Do not send anything. Show me the draft and explain why it matches the context.
Build me a readable HTML page in this workspace that teaches me this system as a beginner. Keep the design clean and make the content practical. Include examples, mistakes to avoid, and reusable prompt templates.
Create a suggested automation for this workflow. Keep it paused and do not activate anything. I want a reviewable draft output first, not automatic sending.