codex-prompting

Codex prompting

Turn the user's request into a bounded task and execute the requested handoff. State the outcome, repository and relevant paths, constraints, write authority, and evidence required for completion. Omit sections that do not help the task.

Model and harness

Honor an explicitly requested model. Otherwise resolve the configured runtime role or inference catalog. Verify availability through the active harness; an old model name in a skill is not configuration. Record the actual model and settings for evaluations.

Use available tools by their real names. Read codex exec --help for CLI flags. Follow the active harness's sandbox, approval, progress-update, and instruction-priority rules. A rejected action is not permission to weaken those controls or retry an equivalent command.

Execution

A clear action request authorizes the necessary work within its scope. Do not stop at a plan or ask again for permission already given. Ask only when a missing decision materially affects the outcome; continue independent work meanwhile.

Load relevant domain skills, not a generic checklist of every infrastructure skill. Keep user instructions above skill preferences. If a skill would block authorized work, name the exact file and rule and resolve the conflict by instruction priority.

For delegation, use the operator's configured orchestration workflow. Give each worker a bounded result and explicit write scope; preserve other sessions' edits. Use completion events or bounded waits, with useful work between checks.

Verification and report

Run checks appropriate to the change. A typo edit needs diff inspection; a behavior change needs evidence for the affected behavior. Do not add repetitive tests or repeat a passing suite without new evidence.

Return the result, artifact or commit, checks and outcomes, and exact unresolved limitations. Do not claim execution, deployment, or delivery from a proposed command.

For prompt changes, consult current official model guidance and compare old/new behavior with harmless fixtures. A model explaining an instruction is a comprehension check, not proof of operational reliability.