Feature flags are one of those things that teams either don't have at all or over-engineer into a third-party service with dozens of features they don't use. Claude Code helps find the middle path.
Starting simple
Most teams need a simple feature flag before they need a sophisticated one. The prompt:
I need feature flags for [use case]. Start simple:
- A single place to define flag names and values
- A function to check if a flag is enabled
- Support for per-environment overrides (dev/staging/prod)
- No external service required
I want to be able to add complexity later if needed, but
not pay for it now. Design it to be extensible but keep
the initial implementation minimal.Claude will design something that works and can grow. Without the "start simple" constraint, it will default to suggesting LaunchDarkly or a full-featured in-house system on day one.
Adding percentage rollouts
When you need gradual rollouts:
Add percentage rollout support to the feature flag system.
Requirements:
- Consistent: same user always gets same result for a given flag
- Deterministic: doesn't require storing per-user state
- Predictable: I can compute "which users are in the 20%" independently
Don't add UI or admin interface yet. Just the logic.The consistency requirement drives toward hashing the user ID against the flag name — consistent without state storage. Claude knows this pattern and implements it cleanly.
Cleanup discipline
Feature flags accumulate. Claude helps with cleanup:
Audit the feature flags in this codebase. For each one:
1. Where is it checked?
2. Are all branches still needed or is one branch dead?
3. Does it look like a temporary flag that should have been removed?
Flag (ha) any that look like candidates for removal without
removing them yet.Old feature flags are tech debt. Running this audit every few months keeps the codebase clean.
Testing with feature flags
Write tests for code that uses feature flags.
For each test:
- Test behavior with flag enabled
- Test behavior with flag disabled
- Don't rely on the flag's current default value in tests
Make it easy to override flag values in test context.The "don't rely on the current default" instruction is important. Tests that implicitly depend on a flag's current state break when the flag changes.
Flag documentation
Each feature flag needs documentation at definition time.
For each flag, require:
- What feature it controls
- When it was added (date)
- Intended removal date or condition
- Owner (who to contact)
- Current rollout status
Generate a template and apply it to the existing flags.Undocumented feature flags are technical debt. This prompt creates documentation inline with the flag definition — it stays current because it's in the same file.
Feature flag patterns and testing prompts are in the Agent Prompt Playbook. $29.