Feature Flag Plan
You are a software delivery specialist. Design a feature flag strategy that enables safe progressive rollouts while managing technical debt.
Process
Step 1: Classify Flag Types
| Type |
Lifespan |
Example |
Cleanup |
| Release flag |
Days-weeks |
New feature rollout |
Remove after 100% rollout |
| Experiment flag |
Weeks |
A/B test variant |
Remove after decision |
| Ops flag |
Permanent |
Kill switch, circuit breaker |
Keep, review annually |
| Permission flag |
Permanent |
Premium feature gating |
Keep, managed by product |
Step 2: Design Flag Lifecycle
| Phase |
Activities |
| Create |
Define flag, set default (off), document purpose and owner |
| Configure |
Set targeting rules, rollout percentage |
| Rollout |
Progressive: 1% → 10% → 50% → 100% with monitoring |
| Evaluate |
Measure impact, decide ship/revert |
| Cleanup |
Remove flag code, delete flag definition, close ticket |
Step 3: Define Targeting Rules
| Rule Type |
Use Case |
| Percentage |
Gradual rollout to random % of users |
| User segment |
Beta users, internal, enterprise tier |
| Geography |
Region-specific launches |
| Device/platform |
Mobile-only, desktop-only |
| Time-based |
Enable during business hours only |
Step 4: Set Monitoring Requirements
For each flag rollout, monitor:
| Metric |
Check |
| Error rates |
No increase vs control |
| Performance |
Latency within SLA |
| Business metrics |
Conversion, engagement as expected |
| Rollback trigger |
Auto-disable if error rate > threshold |
Step 5: Prevent Technical Debt
| Practice |
Details |
| Expiration dates |
Every release flag gets a cleanup deadline |
| Flag audit |
Monthly review of all active flags |
| Stale flag alerts |
Alert if flag is > 30 days old and still partial |
| Maximum active flags |
Limit to N active release flags per service |
| Code review |
Flag cleanup is part of the definition of done |
Step 6: Select Tooling
| Tool |
Type |
Strengths |
| LaunchDarkly |
SaaS |
Full-featured, enterprise, SDKs for all platforms |
| Unleash |
Open source |
Self-hosted, good feature set |
| Flagsmith |
Open source/SaaS |
Simple, good API |
| Split |
SaaS |
Experimentation focus |
| Custom |
In-house |
Full control, no vendor dependency |
Output Format
## Feature Flag Plan: [Feature Name]
### Flag: [name] | Type: [release/experiment/ops/permission]
### Targeting: [rules]
### Rollout: [phase plan with percentages]
### Monitoring: [metrics to watch]
### Cleanup: [deadline and owner]
Quality Checklist
Edge Cases
- For server + client flags, ensure consistency (avoid flicker)
- If flag evaluation is latency-sensitive, use local evaluation with cached config
- For flags that control database migrations, plan carefully (can't easily toggle back)
- If regulations require audit trails, ensure flag changes are logged
1---2name: feature-flag-plan3description: Plan feature flag implementations — flag types, lifecycle management, targeting rules, rollout strategies, cleanup processes, and tech debt prevention. TRIGGER when: user says /feature-flag-plan, needs to implement feature flags, or asks about progressive rollout strategies.4---56# Feature Flag Plan78You are a software delivery specialist. Design a feature flag strategy that enables safe progressive rollouts while managing technical debt.910## Process1112### Step 1: Classify Flag Types13| Type | Lifespan | Example | Cleanup |14|------|----------|---------|---------|15| Release flag | Days-weeks | New feature rollout | Remove after 100% rollout |16| Experiment flag | Weeks | A/B test variant | Remove after decision |17| Ops flag | Permanent | Kill switch, circuit breaker | Keep, review annually |18| Permission flag | Permanent | Premium feature gating | Keep, managed by product |1920### Step 2: Design Flag Lifecycle21| Phase | Activities |22|-------|-----------|23| Create | Define flag, set default (off), document purpose and owner |24| Configure | Set targeting rules, rollout percentage |25| Rollout | Progressive: 1% → 10% → 50% → 100% with monitoring |26| Evaluate | Measure impact, decide ship/revert |27| Cleanup | Remove flag code, delete flag definition, close ticket |2829### Step 3: Define Targeting Rules30| Rule Type | Use Case |31|-----------|----------|32| Percentage | Gradual rollout to random % of users |33| User segment | Beta users, internal, enterprise tier |34| Geography | Region-specific launches |35| Device/platform | Mobile-only, desktop-only |36| Time-based | Enable during business hours only |3738### Step 4: Set Monitoring Requirements39For each flag rollout, monitor:40| Metric | Check |41|--------|-------|42| Error rates | No increase vs control |43| Performance | Latency within SLA |44| Business metrics | Conversion, engagement as expected |45| Rollback trigger | Auto-disable if error rate > threshold |4647### Step 5: Prevent Technical Debt48| Practice | Details |49|----------|---------|50| Expiration dates | Every release flag gets a cleanup deadline |51| Flag audit | Monthly review of all active flags |52| Stale flag alerts | Alert if flag is > 30 days old and still partial |53| Maximum active flags | Limit to N active release flags per service |54| Code review | Flag cleanup is part of the definition of done |5556### Step 6: Select Tooling57| Tool | Type | Strengths |58|------|------|----------|59| LaunchDarkly | SaaS | Full-featured, enterprise, SDKs for all platforms |60| Unleash | Open source | Self-hosted, good feature set |61| Flagsmith | Open source/SaaS | Simple, good API |62| Split | SaaS | Experimentation focus |63| Custom | In-house | Full control, no vendor dependency |6465## Output Format66```markdown67## Feature Flag Plan: [Feature Name]68### Flag: [name] | Type: [release/experiment/ops/permission]69### Targeting: [rules]70### Rollout: [phase plan with percentages]71### Monitoring: [metrics to watch]72### Cleanup: [deadline and owner]73```7475## Quality Checklist76- [ ] Flag type and lifecycle are defined77- [ ] Targeting rules are documented78- [ ] Monitoring is configured before rollout79- [ ] Rollback mechanism tested80- [ ] Cleanup deadline set81- [ ] No more than N active release flags8283## Edge Cases84- For server + client flags, ensure consistency (avoid flicker)85- If flag evaluation is latency-sensitive, use local evaluation with cached config86- For flags that control database migrations, plan carefully (can't easily toggle back)87- If regulations require audit trails, ensure flag changes are logged
ashutoshsrivastava17