Missing decisions are hard to spot for the same reason typos in your own writing are hard to spot. You read what you meant.
This is why "just be more specific" is unhelpful advice. The gaps are not in the places you are looking. They are in the places you have already resolved so completely, so long ago, that you no longer see them as questions at all — and those are precisely the places where someone else's reasonable answer will differ from yours.
So the useful skill is not knowing a list of things to specify. It is having a few reliable ways of making your own description look unfamiliar, so the assumptions inside it become visible. Below are five that work, applied to the same small feature.
The feature is this: a user can upload a profile photo.
Interrogate the nouns
Take each noun in your description and ask three questions of it: what if there are none, what if there is more than one, and what if it is absurd?
User. What if the user is not signed in? Can one user upload a photo for another — an administrator, say? Does everyone have this ability, or only some accounts?
Photo. What if it is not actually an image? What if it is a 40-megabyte image, or eight pixels across? What if it is an image format the software cannot display? What if the user already has one — is it replaced, or is a second one kept? Can they remove it and have none?
Six questions from one noun, none of them clever, and each one an implementation decision that will otherwise be made by something guessing at your intent. The noun test is the highest-yield of the five because software is largely made of things, and things are where absence, duplication and excess live.
Interrogate the verbs
Every action can fail, be repeated, be interrupted, or need undoing. Take the verb and ask about each.
Upload. What happens while it is uploading — is there any indication? What if it fails halfway? What if the connection drops? What if the user presses the button twice? What if they navigate away mid-upload? What if they upload a second photo immediately after the first?
The interrupted case is the one most often missed, and with uploads it is not exotic. It is the ordinary experience of a bad connection.
Verbs also carry the question of reversal. Can this be undone? Should it ask first? For a profile photo the answer is probably that replacement needs no confirmation and removal does — but notice that this is a decision, arrived at by asking, rather than something the description contained.
Count in zero, one, many, too many
Wherever a quantity is possible, walk deliberately through four cases: none, exactly one, several, and more than should be allowed.
For the photo this is quick — a user has zero photos or one. But the fourth case still bites: how many times can someone upload in a minute? If the answer is "as many as they like", that is a decision, and it may be one you would rather have made on purpose than by omission.
The four-case walk earns its keep on anything that produces a collection. It is where limits, ordering and paging come from, and all three are the kind of thing that is trivial to settle in advance and awkward to change once a system has been built around the unstated version.
Walk past the happy ending
Descriptions tend to stop at the moment of success. Keep going, and ask "and then?" three or four times.
The photo uploads successfully. And then? It appears on the profile page. And then? Presumably it appears everywhere else the user is represented — comments, member lists, the navigation bar. Does it? Immediately, or after the page is next loaded? And then? Other people see it. Do they see it at full size, or a smaller version? And then? The user uploads a different one. Does the old one stop being visible everywhere, or does it linger anywhere it was copied?
This is how you find the decisions that live outside the feature you were describing. The upload is one screen; its consequences are spread across the software. Most of the awkward discoveries in AI-assisted work are of this kind — not a mistake inside the change, but a consequence of it that nobody stated.
Ask for the decisions instead of the code
The four techniques above are things you do to your own description. This one uses the assistant, and it is worth doing precisely because the assistant is about to make these decisions anyway.
Before requesting the work, ask for the decisions:
I want users to be able to upload a profile photo. Do not write any code. List the decisions you would have to make to implement this that I have not stated, as questions. Include anything about limits, formats, failures, permissions and what happens to an existing photo.
What comes back is a list of the gaps in your description, produced by the thing that would otherwise have filled them silently. It is genuinely good at this, because enumerating the unstated is a different and easier task than inferring what you wanted.
Two cautions. Answer the questions yourself rather than asking for recommendations — the moment you ask what it suggests, you are back to accepting decisions you have not examined, only now with a paper trail that makes them feel considered. And treat the list as a starting point rather than a complete audit: it will not know that your organisation has a rule about where images may be stored, or that the profile page is about to be redesigned.
Deciding not to decide is also a decision
Every question found this way does not automatically deserve your attention. Some genuinely do not matter, and treating them all as equally important is how a two-minute practice turns into an obstacle.
The distinction worth holding is between a decision you delegated and a decision you missed. "I don't care what the upload progress indicator looks like, anything reasonable" is a delegation — you saw the question, judged it not worth your time, and will not be surprised by the answer. "What happens if the file is not an image" is not something to delegate, because you will care about the answer and you will find out at the worst moment.
A rough test: would you be able to predict the answer, and would you be content with a different one? If you can predict it and would not mind, let it go. If you cannot predict it, or would mind, that is a minute well spent.
Where the answers go
Write the answers as statements rather than questions, because a question in your notes is still an open decision. "Files over 5 MB are rejected with a message before uploading begins" can be built and checked. "What about large files?" cannot.
Then keep them. Decisions settled in one session and not recorded anywhere have a way of being unmade in the next — the mechanism is described in keeping context between AI coding sessions. The behaviour definition template has a section for them, and the fuller account of where this sits in a piece of work is in how to plan an app before you ask AI to build it.