GPT-5.4 Prompting

codex:codex-rescue

• Prefer one clear task per Codex run. Split unrelated asks into separate runs.
• Tell Codex what done looks like. Do not assume it will infer the desired end state.
• Add explicit grounding and verification rules for any task where unsupported guesses would hurt quality.
• Prefer better prompt contracts over raising reasoning or adding long natural-language explanations.
• Use XML tags consistently so the prompt has stable internal structure.

• <task>

  : the concrete job and the relevant repository or failure context.

• <structured_output_contract>

  or

  <compact_output_contract>

  : exact shape, ordering, and brevity requirements.

• <default_follow_through_policy>

  : what Codex should do by default instead of asking routine questions.

• <verification_loop>

  or

  <completeness_contract>

  : required for debugging, implementation, or risky fixes.

• <grounding_rules>

  or

  <citation_rules>

  : required for review, research, or anything that could drift into unsupported claims.

• Coding or debugging: add

  completeness_contract

  ,

  verification_loop

  , and

  missing_context_gating

  .
• Review or adversarial review: add

  grounding_rules

  ,

  structured_output_contract

  , and

  dig_deeper_nudge

  .
• Research or recommendation tasks: add

  research_mode

  and

  citation_rules

  .
• Write-capable tasks: add

  action_safety

  so Codex stays narrow and avoids unrelated refactors.

• Use built-in

  review

  or

  adversarial-review

  commands when the job is reviewing local git changes. Those prompts already carry the review contract.
• Use

  task

  when the task is diagnosis, planning, research, or implementation and you need to control the prompt more directly.
• Use

  task --resume-last

  for follow-up instructions on the same Codex thread. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.

• Prefer explicit prompt contracts over vague nudges.
• Use stable XML tag names that match the block names from the reference file.
• Do not raise reasoning or complexity first. Tighten the prompt and verification rules before escalating.
• Ask Codex for brief, outcome-based progress updates only when the task is long-running or tool-heavy.
• Keep claims anchored to observed evidence. If something is a hypothesis, say so.

1. Define the exact task and scope in

   <task>

   .
2. Choose the smallest output contract that still makes the answer easy to use.
3. Decide whether Codex should keep going by default or stop for missing high-risk details.
4. Add verification, grounding, and safety tags only where the task needs them.
5. Remove redundant instructions before sending the prompt.