The scenario
Existing account code can be inspected, but membership, role and ownership rules have not been decided.
Required context: a selected repository matching this scenario, relevant task evidence, and access to its instructions and checks. Use redacted or synthetic data where appropriate.
Adapt the complete prompt
Edits stay in this browser tab. Saving bookmarks the original example; export your edited version to keep it elsewhere.
Why this is a strong example
It uses the agent to surface missing decisions instead of merely making a vague request longer.
A concrete outcome
Turn “add team accounts” into an implementation-ready task brief without starting implementation.
The result can be assessed against an observable task rather than prompt length or confidence.
Boundaries and a method
Inspect what already exists. Ask the few product questions that affect access, shared data and scope; propose defaults only for low-risk details and label assumptions.
This leaves implementation judgment while constraining the changes that would exceed the task.
Evidence that can disagree
Return agreed behavior, non-goals, example acceptance cases, unresolved decisions and a verification plan. Do not invent answers to consequential questions.
These checks describe what would make acceptance justified; asking for them does not mean they ran.
A safe way to encounter uncertainty
If the repository contradicts these assumptions, required access is unavailable, or a consequential product decision is missing, explain the conflict and pause the dependent work. Preserve unrelated changes.
Consequential uncertainty stays visible rather than being converted into an invented requirement.