Codex Goal Prompting

Codex Goal prompts must fit Codex's goal objective limit: 4,000 characters max, including whitespace. Aim for 3,500 characters or less to leave room for command wrappers or edits. For broad work, write the full instructions to goal.md in the repo root unless the repo has a clearer documented convention. The short /goal objective must explicitly reference goal.md.

Within that limit, prompts should be short enough to preserve autonomy, but concrete enough to convey intent. A strong prompt is usually 2–4 compact sections: goal, functional scope, hard boundaries, and proof. Use bullets for scope when they clarify product intent; avoid file-by-file or implementation-by-implementation checklists.

The key is to ask Codex to own the solution: investigate first, compare data to product behavior, notice oddities, iterate, clean up, and prove the outcome on the affected real surfaces. If testing exposes an in-scope bug, Codex should fix it and retest instead of stopping at task-shaped completion. Do not require irrelevant interfaces: use agent-browser only for web/app changes, pilotty/TUI capture only for TUI changes, API e2e only for API/contract changes, etc. Prefer real/local services without mocks or fixtures for product proof; fixtures are supporting tests, not user-visible proof.

Default Pattern

Goal: <product outcome and why it matters>. <Current failure mode/example>. Own the solution: inspect the relevant code/data/UI, decide the cleanest approach, iterate when something looks off, and do not reduce this to a checklist-shaped change.

Functional scope:
- <compact set of product capabilities/outcomes, not exact implementation steps>
- <include explicit deferrals when important>

Hard boundaries: <anti-goals/contracts>. Do not <known bad paths>.