Practice workspaceY
Better task judgment
PRACTICAL CODEX LESSON

Ask the question the repository cannot answer

Separate discoverable facts from product decisions, ask consequential questions, and turn answers into a bounded brief.

01 / PREDICT

You are asked to add team accounts. Which unknown can code inspection resolve, and which decision belongs to the product owner?

Write a brief prediction before opening the explanation.

02 / EXPLAIN
Read the lesson

Sort the unknown before asking

A vague request can hide different kinds of missing information. Existing tables, components and test commands can usually be inspected. Membership rules, ownership after someone leaves a team, and who may invite a colleague are product decisions. A repository can show current behavior; it cannot decide what a new feature ought to mean. Label each unknown as inspectable, decision required, or a reversible implementation detail.

Ask questions that change the work

A useful interview is bounded by the requested outcome. Ask a small number of questions whose answers change visible behavior, data ownership, authorization or release scope. Explain the consequence of each choice. Avoid making the user choose local variable names or rediscover package scripts that are already on disk. Offer a reasoned default for low-risk details, and record it as an assumption rather than quietly treating it as an approved requirement.

Turn the answers into a contract

After the interview, summarize the agreed behavior with examples, boundaries, unresolved decisions and observable checks. Ask the owner to resolve consequential ambiguity before implementing that part. Keep useful repository inspection moving while waiting. Carry the resulting brief into execution; a long transcript of abandoned options is less useful than the decisions and evidence that still apply. A fresh session is optional, not a requirement.

Common mistake

Interviewing the user about facts the repository already contains—or inventing membership rules to avoid asking.

03 / DEMONSTRATE

Make the request actionable

A weak starting brief: Add team accounts and handle invitations sensibly.

Inspect the current account model, invitation flow and repository instructions. Before implementing team membership, identify product decisions the code cannot settle. Ask the few questions that affect access, ownership or scope, explaining the tradeoffs. Then draft a brief with agreed rules, non-goals and verification cases. Keep unresolved decisions explicit.

This example is an adaptable request, not evidence that a runtime action has executed.

04 / PRACTICE

Team invitations

Repository snapshot: accounts and password login already exist. The manifest lists the test command. No team membership rules have been specified. Request: let users invite colleagues to a team.

Simulated scenario · No repository access or command execution

What should Codex clarify with the product owner before implementing access rules?

Loading your saved lesson progress…