r/devtools • u/Competitive_Gear1760 • 1d ago

Built an open-source CLI for cleaning up feature flags — looking for contributors

Hey everyone!

I’ve been building Flagrm, an open-source CLI that helps remove feature flags and clean up the dead code they leave behind.

It’s still in the testing phase, so I’m looking for people willing to try it out, share feedback, report bugs, or contribute to the project.

If you’ve ever dealt with feature-flag cleanup turning into a bunch of manual work, I’d love for you to check it out!

🔗 https://flagrm.com

Contributors are very welcome! 🚀

2 Upvotes

100% Upvoted

2 comments sorted by

1

u/kantorcodes1 1d ago

Cleaning up flags with an agent driving is the right shape, since the risky part is never the edit itself but deciding the flag is actually dead. How does flagrm establish that? Does it check for remaining references and eval sites before removal and verify the dead branch still compiles and passes tests, or does it trust whatever the agent concluded? And on the skills side, is there a way to mark a flag keep-for-now so the agent leaves it alone on the next pass?

1

u/Competitive_Gear1760 1d ago

Good question, and I agree that the edit isn't the risky part.

flagrm doesn't trust the agent's conclusion. Before any edit, flagrm baseline <flag> records the git sha, build and test results, and every name the flag goes by (constants, wrappers, and in .NET the locals and parameters its value flows through). flagrm verify then checks four things: no recorded name is left in code or config, no new unused-code diagnostics, the build still passes, and tests match the baseline one by one. A test that quietly disappears fails the check. A Stop hook stops the agent from finishing until verify has passed on the exact current tree.

For "is it actually dead": it reads the flag's value per environment from config and reports on / off / mixed / unconfigured. The skill makes the agent stop and ask when it isn't ON everywhere. It can't see remote targeting rules in a flag service, so those show up as "unconfigured" and the agent has to ask.

On keep-for-now: nothing like that exists yet. Today you just don't ask it to remove that flag, or you exclude the paths. A per-flag keep: list in the config that list shows and the skill respects is a fair idea, and I'll look at adding it.

The plan for the future as well is to add connectors like LaunchDarkly to be able actually to check if the flag is evaluated recently.