Good Codex prompts state the goal, point to the right files, set the one or two limits that matter, and say what done looks like so Codex can check its own work. Below are 14 original prompts for OpenAI Codex in the CLI, IDE extension and app, built on the features OpenAI documents: plan mode, AGENTS.md, /review, subagents, skills and codex exec.
How to use these prompts
Paste a prompt into the Codex composer and replace the blanks in double braces, or keep the default after the colon: {{test_command:npm test}} means npm test unless you change it. Where a prompt names a file, use an @ mention so Codex attaches it.
OpenAI's Codex best practices recommend four parts in every prompt: Goal, Context, Constraints and Done when. The prompts below follow that shape. The features they rely on:
| Feature | What it does | How to reach it |
|---|---|---|
| Plan mode | Investigates and proposes an approach before editing | /plan or Shift+Tab |
| AGENTS.md | Project instructions Codex loads automatically | /init scaffolds one |
/review |
Reviews a diff and reports findings without editing files | /review, then pick a preset |
| Subagents | Parallel agents for bounded work, when you or your instructions ask | Ask in the prompt; /subagents to inspect |
| Skills | Reusable workflows in a SKILL.md folder |
Type $ to invoke one |
codex exec |
Runs Codex without the interactive UI | Scripts and CI |
Pick reasoning effort to match the job: the best practices page suggests Low for well-scoped work, Medium or High for complex changes and debugging, and Extra High for long, reasoning-heavy tasks.
How do you plan before Codex writes code?
1. Map an unfamiliar repo (plan mode)
Toggle plan mode first so Codex reads without editing.
I'm new to this repository. Without changing any files, explain:
1. What the project does, in two sentences.
2. The main folders and what lives in each.
3. How a request travels from {{entry_point:the HTTP router}} to the database.
4. The build, test and lint commands, and where they are defined.
5. The three files I should read first to understand {{area:billing}}.
Cite a file path for every claim. Say "unclear" instead of guessing.
2. Interview me before planning
The best practices page suggests asking Codex to question you and challenge your assumptions before it writes code. Use this for features where you are not sure what you want yet.
I want to build {{feature:a CSV export for the reports page}}.
Before you plan or write anything, interview me. Ask one question at a
time about scope, edge cases, data volume, permissions and failure
handling. Challenge any assumption that looks wrong given the code you
can see. When you have enough, summarize the agreed requirements as a
short list and wait for my OK.
3. Plan a multi-file change
Run this in plan mode. Codex proposes the approach and you approve it before any edit.
Goal: {{goal:add rate limiting to the public API}}.
Context: start from {{start_file:src/api/router.ts}} and the existing
middleware folder.
Constraints: no new dependencies unless you justify them; keep the
public response format unchanged.
Done when: {{done_check:npm test and npm run typecheck}} pass and every
new code path has a test.
Write a numbered plan: files to change, what changes in each, the tests
you will add, and the risks. List open questions at the end.
4. Write an execution plan for a long task
For work that spans many steps or sessions, OpenAI points to a PLANS.md execution plan. This prompt asks Codex to write one you can keep in the repo.
We are going to {{project:migrate the app from REST calls to the new GraphQL client}}.
This will take several sessions.
Create PLANS.md with: the goal, the current state, milestones in order,
for each milestone the files involved and a command that proves it is
done, decisions made so far, and open questions. Keep it under two
pages. Do not start the migration yet.
How do you get Codex to fix and build things safely?
5. Fix a bug with a regression test
OpenAI's own sample constraint for bug fixes is "Keep the fix minimal and add a regression test if feasible." This prompt builds on it.
Bug: {{symptom:users are logged out after refreshing the page}}.
Steps to reproduce: {{steps:log in, refresh, check the session cookie}}.
Likely area: {{area:src/auth}}.
First write a failing test that reproduces the bug and show me it
fails. Then fix the root cause with the smallest change that works.
Don't suppress errors or loosen checks. Run {{test_command:npm test}}
until it passes and summarize the cause in two sentences.
6. Build from a screenshot
Paste the image into the composer or start the CLI with codex --image. The Codex images guide covers the options.
Build the attached design as {{component:a pricing card component}} in
{{framework:React with Tailwind}}.
Match spacing, type sizes and colors as closely as you can, reusing our
existing tokens in {{tokens_file:src/styles/theme.ts}}. Don't add new
libraries. When done, list anything in the image you could not match
and why.
7. Refactor in small, testable steps
Refactor {{target:src/utils/date.ts}} to {{goal:remove the moment.js dependency}}.
Keep behavior identical. Work in small steps: after each step run
{{test_command:npm test}} and stop if anything fails. Don't change
public function names or signatures. At the end, list every file you
touched and one line on why.
How do you review code with Codex?
8. Custom focus for /review
In the CLI, type /review and choose Custom review instructions, then paste this. Codex starts a dedicated reviewer that reports findings without changing your working tree, as described in OpenAI's code review docs. More on presets in the Codex review guide.
Review this diff as a strict senior engineer. In priority order: bugs
and wrong logic, security ({{security_focus:auth checks, injection, secrets in code}}),
missing error handling, missing tests. For each finding give the file
and line, severity (blocker, should fix, nit), the problem and the fix.
Skip anything our linter already catches.
9. Review a branch with parallel subagents
Local Codex spawns subagents when you ask directly, or when AGENTS.md or a skill tells it to. This wording follows the example in OpenAI's subagents docs. See the Codex subagents guide for custom agents.
Review this branch against {{base_branch:main}} with parallel subagents.
Spawn one subagent for security risks, one for test gaps and one for
{{third_focus:performance regressions}}. Wait for all of them, then give
me one merged list sorted by severity, with duplicates removed and file
and line for each finding. Don't edit any files.
10. Ask for a focused review on a GitHub pull request
Post this as a pull request comment. OpenAI's GitHub docs say @codex review accepts a focus after it, and @codex security review runs a security review.
@codex review for {{focus:issues in the database migration and missing rollback steps}}
How do you set up AGENTS.md and skills?
11. Tighten the AGENTS.md that /init created
Run /init first. The best practices page says AGENTS.md should cover repo layout, how to run, build, test and lint, conventions, do-not rules and how to verify work. OpenAI's AGENTS.md docs explain discovery order and the 32 KiB default size limit, and the Codex AGENTS.md guide has examples.
Read AGENTS.md and check every command in it by running it. Then
rewrite the file so it:
- lists the exact build, test, lint and typecheck commands that work
- names the main folders in one line each
- states our conventions only where they differ from the language's defaults
- includes a "do not" list: {{do_not:never edit generated files in src/gen, never commit .env}}
- ends with how to verify a change before calling it done
Cut anything you could learn by reading the code. Keep it under 80 lines.
12. Turn a repeated mistake into a rule
The best practices page suggests a retrospective when Codex makes the same mistake twice.
You have now {{mistake:used the old logger instead of src/lib/log.ts}}
twice. Do a short retrospective: what in the code or instructions led
you there? Then propose one rule for AGENTS.md, worded so it would have
prevented this, and say which AGENTS.md file it belongs in (root or a
subfolder closer to the code). Show me the rule before adding it.
13. Turn a repeated prompt into a skill
OpenAI's rule of thumb: if you keep repeating the same prompt or correction, make it a skill. Team skills live in .agents/skills in the repo. The Codex skills guide has the details.
Create a skill named {{skill_name:release-notes}} that
{{job:writes release notes from the commits since the last tag}}.
Save it as .agents/skills/{{skill_name:release-notes}}/SKILL.md with a
name and a description that says what it does and when to use it,
including phrases I might type. In the body, give numbered steps, the
exact output format, and two rules about what to leave out. Then tell
me how to invoke it with $.
How do you use Codex in scripts and CI?
14. A prompt for codex exec
codex exec runs Codex non-interactively in scripts and CI pipelines; the codex exec guide covers flags and output. Write prompts for it so they never need a follow-up question.
Read the failing CI log in {{log_file:ci-output.txt}}. Identify the
first real failure, not the cascade after it. Fix it with the smallest
change, run {{test_command:npm test}} to confirm, and print a final
summary in this exact form:
CAUSE: one sentence
FIX: files changed
STATUS: PASS or FAIL
What makes a Codex prompt work?
Most weak prompts are missing the last part: what done looks like. Without a command to run, Codex can only judge its work by reading it. Name the test, build or lint command in the prompt, or better, put it in AGENTS.md once so every prompt inherits it.
Keep one chat per unit of work, and fork only when the work really branches. OpenAI's list of common mistakes includes putting durable rules in prompts instead of AGENTS.md or skills, skipping planning on complex tasks, and running live tasks on the same files without Git worktrees. If you want more structure around approvals, see the approvals and sandbox guide and the Codex cheat sheet.
The same prompts translate to other agents with small changes. The Claude Code prompts, GitHub Copilot prompts and Gemini CLI prompts use each tool's own features, and the code review prompts work anywhere.
Keep your best Codex prompts in one place
Prompts like these are worth keeping. Kipt stores them as Markdown in a private GitHub repo you own: save a prompt with its blanks, tag it, and find it again with Cmd+K. When one becomes a workflow, the free SKILL.md generator turns it into a valid SKILL.md, and Kipt can install your skills into Codex with one npx skills add command.