What this page answers
- What feature flag lifecycle management means when Codex, Claude Code, Copilot, FeatBit CLI, and FeatBit MCP are part of the workflow.
- Why flag type and cleanup expectation should be decided before implementation starts.
- How FeatBit state and repository rules work together so agents can support rollout, review, and cleanup.
Every flag needs a lifecycle contract
A feature flag is more than a conditional branch. It is a release object with a purpose, lifecycle type, target audience, expected lifetime, and end state.
In the AI era, that contract should be readable by humans and by coding agents. The agent cannot infer your team's release policy from a flag key alone; it needs explicit rules close to the codebase.
The lifecycle has eight steps
FeatBit's lifecycle model starts with flag type and cleanup expectations, then moves through creation, implementation, monitoring, release decisions, stale detection, and cleanup.
This sequence matters because cleanup is only safe when the earlier steps created enough evidence. A flag with no type, no rollout history, and no implementation convention is hard for both people and agents to remove later.
- Define the type before the flag is used.
- Set the cleanup expectation before the rollout begins.
- Keep implementation predictable so the cleanup path is searchable.
- Use release health and experiment evidence to decide whether the new path should become permanent.
Agents should collaborate across product and code state
Repository search answers where the flag is used. FeatBit answers what the flag has done: rollout changes, tags, audit history, archived state, and experiment context.
When an agent can read both, it can prepare a better review than either source allows alone. That is the shift from code completion to lifecycle collaboration.
Use the lifecycle map as the source of detail
The website page explains the framework. The docs page expands each lifecycle step with CLI, MCP, and implementation guidance.
Open the lifecycle docs