Help users discover missing requirements before Codex starts coding

What variant of Codex are you using?

App

What feature would you like to see?

Problem

When users ask Codex to build something, the request often contains important but unstated requirements—especially for UI, games, interactions, animations, visual design, and user experience.

Codex may reasonably fill in those gaps based on common patterns, but the result can still be fundamentally different from what the user intended.

The user then has to discover the mismatches only after seeing the generated result and spend additional turns correcting them.

This creates a loop:

Prompt → Codex guesses missing requirements → implementation → user discovers mismatch → repeated corrections

The problem is not necessarily coding quality. It is missing product/design context before implementation begins.

Use case

For example, a user might say:

“Build a cute physics-based game with a little ball.”

The user may have very specific ideas about:

• visual style
• proportions
• color mood
• animation feel
• physics behavior
• interaction feedback
• UI style

But they may not know how to express all of these requirements in a prompt.

Suggested direction

Before starting implementation, Codex could optionally analyze the request and identify missing information that is likely to materially affect the final result.

Instead of asking everything, Codex should ask only the highest-impact clarification questions.

For example:

“Before I start, I see 3 decisions that could significantly affect the result:

1. Should the ball feel soft and cartoon-like or physically realistic?
2. Should the UI be minimal or game-like?
3. Should the physics feel realistic or intentionally soft/slow?”

The user answers these questions, Codex forms a concise confirmed specification, and then begins implementation.

Why this matters

This would allow users who cannot write a perfect prompt to still communicate their actual intent.

It could make Codex less like:

“Give me a prompt and I will generate code.”

and more like:

“Tell me what you want to make. I will help you clarify it, then build it.”

The key is not to make Codex ask more questions.

The key is for Codex to become better at recognizing:

“I don't have enough information to make a good implementation yet, and this particular missing information will significantly affect the result.”

The challenge is not simply that users cannot write good prompts. Sometimes users themselves do not know which details need to be specified until they see the first result. The first generated version helps them discover what they actually care about. Codex could proactively surface these hidden decisions before implementation.

Additional information

The challenge is not simply that users cannot write good prompts. Sometimes users themselves do not know which details need to be specified until they see the first result.

For example, when building a game, a user may have an intuitive sense that the physics feel “too hard,” the visual hierarchy feels wrong, or the colors lack the intended emotion, without knowing how to express those requirements upfront.

The first generated version can help users discover what they actually care about. Codex could proactively identify these hidden decisions and ask targeted clarification questions before implementation, rather than requiring users to discover and communicate every missing requirement through repeated iterations.

The goal is not to make Codex ask more questions, but to help it recognize which unanswered questions are most likely to affect the final result.

No files, tests, or entry points are named. Start by locating the Codex request-handling and user-interaction flows, then define how high-impact missing requirements are identified, presented, confirmed, and verified without making clarification questions overly broad.