The skill isn't to write software without requirements. It is instead to elicit requirements from the project owner regardless of whether there is a formal requirements documentation or not.

Gathering requirements is definitely your first priority, but you don't necessarily need to get all of the customer's needs noted up front. The risk is of course is that you might miss some vital piece of information that renders your system architecture useless if you haven't managed to have the right sort of conversations with your customer, however it is not unusual to define a product and even get much of the development out of the way, while deferring the major system architecture decisions until the last possible moment. This is a lean development approach which is meant to ensure that you don't commit to a potentially incompatible architecture too early in your product development until you have more solid information. In the situations the OP has described in his question, this lean approach would be quite important IMHO to avoid major rework and cost blow-out later on, which is when you've finally managed to learn what it was your customer really needed.

Yes, you do sometimes need to crystal-ball-gaze a little to get to the heart of what it is the customer really is asking for, which is where prototyping spikes and the slow - and yes sometimes painful - incremental drawing out of requirements requires that you really develop good customer relationship skills, and also the patience to realize that with any complex software idea, that in the beginning the customer doesn't often know much more than you about what the software actually needs to do. Most often, the customer calls you in early to depend on your expertise to define their requirements as the customer doesn't always have the necessary expertise or knowledge of the software development process.