What this page answers
- How to use coding agents for stale feature flag cleanup without deleting active operational or business flags.
- What evidence an agent should collect from FeatBit, repository references, tests, telemetry, and release context.
- Why the safe order is code cleanup first, production deploy second, FeatBit archive or delete last.
Start from a candidate, not a hunch
The safest cleanup flow begins with stale flag detection. The agent should compare FeatBit state and repository usage against cleanup expectations, then classify the flag before editing code.
This prevents the common mistake of deleting a flag just because it looks old. Long-lived permission, operational, and configuration flags can be old and still correct.
Require evidence before edits
Before editing, the agent should list the flag key, registry entry, evaluation helper, component props, tests, tracking events, linked rollout or experiment context, and any module-level dependencies.
That short evidence block belongs in the pull request. It helps reviewers see why the permanent path was chosen and what changed.
- FeatBit tags and lifecycle type
- Rollout state and audit history
- Experiment state or recorded decision
- Repository references for key and typed registry name
- Tests and telemetry connected to the flagged path
Remove code first, then archive the flag
The application should stop evaluating the flag before the FeatBit flag is archived or deleted. That order preserves rollback safety while the code change is being deployed.
After production no longer evaluates the flag, the FeatBit record can be archived or deleted according to your team's history policy.
Use agents for cleanup, but make the workflow explicit
The detailed cleanup guide shows how to extend a feature flag agent skill with stale detection and removal rules.
Read the cleanup workflow