Perhaps I want to hold it to my own standard for tooling, not the team’s.
Perhaps I want to write it in a language that the team doesn’t really embrace.
I might not think it’s worth anyone’s time to code review changes I make to my own tools.
I might want to do something dumb like bake an API key into the tool.
Maybe the project already has a similar tool, and I don’t want to explain why I am wrapping/ignoring it.
In short: sometimes the cost to collaborate on idiosyncratic tools is just higher than I’m willing to pay.
I just want to hack together something that works for my use case. If I can share that with the wider team, that is superb. But I really don't enjoy my hacky utils being subject to tedious code review scrutiny they don't deserve.
To be clear, I _do_ add utils that I think will be useful to the common repo, subject to review, and mostly they will be merged. But if it gets painful, I just retract the PR and keep it locally.
What an extraordinary amount of unnecessary effort that would be. My workflow does not belong to the repo, it belongs to me. The only thing that belongs in the repo is all the shared workflows (or the elements they comprise.)
I also tend to put a Makefile into the root of any repo I work in (ignored via .git/info/exclude), so that shell commands relevant to my workflow can accumulate under that Makefile. I've been doing this for at least 10 years and love it. Most repos have some sort of a cli interface, but that doesn't mean that they're any good. Make is nice way to wrap all of them, and to standardize on at least the build/test/run commands across many disparate repos.
Here's an example of one of those from a long-abandoned project: https://gist.github.com/staticshock/0e88a3232038d14a2817e105...