I'm sorry, but that's only a good way to approach Lisp programming when you know everything that your language comes with, and are sure that none of it provides a good representation for the problem.
Otherwise, the way to approach Lisp programming is the same as with any other language: how can the existing syntax and library features (such as macros!) be orchestrated to solve this problem?
Which kinds of macros would be useful will become apparent during development. You often don't know what language features may be nice to have until you have worked in that problem domain.
Lisp programming sometimes happens without knowing what the ideal language of the problem domain would look like; you don't know that upfront to just it down and make macros for it.
Secondly, there may be third-party libraries for the problem domain. For instance, if you're sure that the problem domain requires solving goals stated as queries over logical predicates, that doesn't mean you have to implement your own Prolog in macros.
So the priority is roughly: built-in macros > stable third-party macros > experimental/own macros.