there are multiple levels to this: from Smalltalk-like self-hosted-ness and moldability (just change how the object behaves live, and use it to solve the problem at hand), to more nuanced in-tool generative potential (make your own swatches in Photoshop "on the side", show history of the design work by duplicating frames in Figma, etc.)
the former (the Smalltalk-like approach), is related to the ideas of Fractality of Software Tools - everything is objects within objects (or functions within functions in Lisp-land), and when you can change how they behave, you can make your own tools in the tool
the latter is also very interesting, but seems more like a "happy accident" than planning for this explicitly
maybe it's not so much "tool building" but "functionality building"?
since Achieving Cognitive Fit is Easier than Social Fit maybe instead of focusing on strategies for adopting tools (achieving "social fit") a good tool-making kit would allow users to create their own cognitively-fitted tools without having to worry about the social fit (making tools just for themselves)
Dynamic spreadsheets were invented by Daniel Bricklin and Robert Frankston as a reaction to the frustration Bricklin felt when he had to work with the old ruled-paper versions in business school. They were surprised by the success of the idea and by the fact that most people who bought the first spreadsheet program (VisiCalc) exploited it to forecast the future rather than to account for the past. Seeking to develop a "smart editor", they had created a simulation tool.
developers should be Second-Order Tool Builders - allowing domain experts and end users to build the tools they need, in the tools provided by developers