Turn Intent Into Verifiable Work

You do not need to know the implementation to specify valuable work. You do need to explain who experiences the problem, what decision or action is difficult today, which information matters, and what a trustworthy result looks like. That is domain judgment, and it is often harder to replace than syntax knowledge.

Codex can inspect a codebase and propose implementation details. It cannot safely decide an unstated business rule, permission policy, financial threshold, or customer promise. Separate the decisions you own from the technical questions the agent may investigate. Mark unknowns instead of allowing fluent guesses to become requirements.

A useful task contract names the outcome, user, starting evidence, allowed scope, constraints, non-goals, acceptance cases, required proof, and conditions that require a pause. It does not prescribe every line of code. It tells Codex what must remain true while leaving room to discover the best local implementation.

Include examples where language is ambiguous. For a status workflow, specify allowed transitions and one rejected transition. For a report, provide a representative input and the expected shape. For an interface, name the critical user journey and responsive states. Examples convert taste and business logic into material that can be tested.

Ask Codex to inspect the repository's own instructions, manifest, entry points, relevant data model, neighboring implementation patterns, tests, and current Git state. Require exact paths. A README can describe the intended system, while the current source and runtime may tell a different story. Label each conclusion confirmed, inferred, or unknown.

Trace one vertical path instead of cataloging every file. Follow the user's action into the interface, through logic, into state or an integration, and back to the visible response. This gives technical pieces a purpose and reveals the smallest set of responsibilities the change must cross.

Different questions require different proof. A typecheck can show that TypeScript agrees with the program's types. A unit test can show that one function handles a known case. A browser run can show that a user can complete the actual flow. A provider receipt can show which release was deployed. None proves all the others.

State the minimum evidence required before implementation begins. High-risk work needs negative cases as well as happy paths: an unauthorized user is rejected, a duplicate event is harmless, a missing value produces a clear error, or a failed publish leaves the previous release available. Evidence should follow the risk, not a generic checklist.

A strong task tells Codex when it may make a reasonable implementation assumption and when it must pause. Pause when two product interpretations lead to meaningfully different behavior, when the requested action affects an external person or production system, when a secret or new permission is required, or when existing user work overlaps the necessary files.

Do not turn every small uncertainty into a meeting. Give the agent authority to resolve local, reversible implementation details that preserve the contract. The goal is bounded autonomy: freedom inside an explicit box, with escalation at the edges.