Interesting idea, it’s like running an integration test for someone else’s tool. I did something a bit like this for a few internal tools I built at Airbnb. I

Interesting idea, it’s like running an integration test for someone else’s tool. I did something a bit like this for a few internal tools I built at Airbnb. I built a docs system that indexed all the markdown files in every repo or project’s .infra/docs folder into a central documentation browser website. Then in each tool project, we had a CI job that would loop over all the commands and spit the —-help output in Markdown format into that folder. That way when someone added commands or changed a command’s args or help text, the searchable docs were automatically updated. We didn’t use this to generate a change log to show to users per se, but it did mean that you could run `git log .infra/docs` to see a log of every change to the tool’s interface.