codex-prompting

Codex Prompting

Use this skill only to shape a request before forwarding it to Codex. Model selection remains a runtime concern: leave --model unset unless the user explicitly chooses one, so Codex can honor its user-level or project-level configuration.

Core rules

• Lead with the outcome, not a prescribed sequence of steps.
• State the success criteria and stopping condition that determine when the task is complete.
• Preserve user-provided values, scope, output contracts, permissions, and safety boundaries exactly.
• Expose only task-relevant context and tools.
• Require evidence and validation where correctness depends on them.
• Remove repeated instructions, generic "be concise/thorough" language, and examples that do not change behavior.
• Prefer the current prompt plus a measured correction over a wholesale rewrite after a regression.

Recommended shape

Use only the sections that materially constrain the task:

Goal: [user-visible outcome]

Success criteria:
- [observable completion condition]

Constraints:
- [scope, permissions, evidence, safety, or compatibility rules]

Output: [required artifact or response shape]

Stop rules: [when to retry, ask, report a blocker, or finish]

Add role, personality, collaboration style, or tool-routing guidance only when the request genuinely depends on it. XML blocks remain available for strict downstream contracts or risky workflows, but they are not the default prompt shape.

Autonomy and tools

• Distinguish planning, diagnosis, implementation, review, and external coordination.
• For implementation, authorize in-scope local edits and relevant non-destructive validation explicitly.
• Require confirmation for destructive actions, external writes, purchases, or material scope expansion.
• State prerequisite retrieval or validation steps when they cannot be skipped safely.
• Parallelize independent reads; keep dependent actions sequential.
• When a tool result is empty, partial, or suspiciously narrow, try a bounded fallback before concluding.

Reasoning effort

• Leave effort unset unless the user explicitly requests it or a measured workload requires a pinned level.
• GPT-5.6 Sol supports low, medium, high, xhigh, max, and ultra in current Codex catalogs.
• Start from the configured effort, then compare the same level and one level lower on representative work.
• Use max or ultra only for difficult quality-first work where evaluation shows a real gain.
• Tighten missing success criteria, tool routing, or validation before increasing effort.

Validation

For coding work, request the smallest checks that can disprove the result: targeted tests, type or lint checks where applicable, affected builds, and a realistic smoke for runtime changes. If a required check cannot run, require the final answer to name the blocker and remaining risk.

Prompt assembly checklist

1. Preserve the user's exact goal and material constraints.
2. Define observable success and a stopping condition.
3. Add only the context, tools, and output requirements that affect behavior.
4. Make permission and validation boundaries explicit.
5. Remove redundant scaffolding before forwarding.

Reusable strict-contract blocks live in references/prompt-blocks.md. Concrete task templates live in references/codex-prompt-recipes.md. Common failure modes live in references/codex-prompt-antipatterns.md.