edit: What the other commenter said about documentation nailed it. THat’s where I was going anyway. You have to figure out the patterns you’re _already using_ to deliver software to your clients. “Reify” them. Make them into “official” tools in your official professional toolkit :)
As you get more experience recognizing the patterns you’ve already discovered with reason and instinct. You’ll start to recognize patterns between tools, and patterns between problems. And you will see more opportunities for tools/techniques that solve wide swaths of problems.
I have a kitchen drawer full of really handy React hook I’ve written over the past couple years, for example, that are generalized enough to work anywhere.
FYI, I'm a data scientist that does front-end development as the reporting tool. Most of my projects involves creating some data analysis pipeline and then putting a frontend on it.
I’m basing this on how, when I want to learn about a new thing, I have the most success when I start by googling, “What kinds of _____ are there?” Just seeing the categories of the thing I’m trying to learn there are helps me a lot.
So maybe developing your own descriptive language for the kinds of projects you generally undertake would be a … well, now I’m just circling back to the documentation thing.
You seem like you’ve got your stuff together!