A CLI the whole team ships through

Two problems, both worth solving once rather than every week.

Neither looked like a problem from outside. Nothing was broken, nothing was on fire, and both had a workaround a careful person could hold in their head. That is what made them expensive: the cost was spread thin across every week and every person, so it never arrived as something to fix, only as something to be careful about.

The first is that a project can have two owners writing into one file tree. Developers own the code, while someone else, a client or a QA reviewer, owns the configuration they edit through a live editor, and git only ever had a copy of one of those. Deploy a branch over the top and the half you do not own is gone, silently. Everyone knew the rule. It was written down. It still went wrong, because knowing a rule and remembering it at 6pm on a Friday are different things. So syncing needed a senior developer watching, which meant waiting for one.

The second is consistency. Across a lot of client projects, conventions drift: different folder structures, different patterns, different AI rules, different output depending on who picked the job up. Code review catches that eventually, which is a slow and expensive place to catch it.

I started building this on my own initiative to fix both, because they turned out to be the same problem: things the team is supposed to remember should be things the tool already does.

Most of the work was not the code. It was watching where the time actually went, separating the part that was genuinely different per client from the part we were rebuilding every time, and deciding what the tool should refuse to do rather than only what it should make easy. Writing the commands afterwards was the short part.

None of it is specific to one platform. The shape of it, two owners writing into one tree and conventions drifting apart across projects, turns up anywhere a team runs more than a handful of repositories.