Feature Flag Cleanup Planner

What this skill does

Pulls a feature-flag inventory and the codebase that consumes them, finds flags older than 90 days, and produces a per-flag plan: keep (still rolling out), promote-on (remove the false branch), or sunset (remove the true branch).

Inputs

• flag_provider: launchdarkly, unleash, statsig, flipt, or custom.
• flag_inventory: when custom, a CSV with key, created_at, current_state (provider integrations fetch the inventory directly).
• repo_dir: source root containing flag references.
• Optional age_threshold_days: defaults to 90.

Steps

1. Fetch flags. LaunchDarkly: curl -H "Authorization: $LD_API_KEY" https://app.launchdarkly.com/api/v2/flags/<env>. Otherwise read flag_inventory.
2. Filter to flags with created_at < now - age_threshold_days.
3. For each flag, count call sites in repo_dir: rg -nN '"<flag_key>"|\.<flag_key>\b' --type-add 'src:*.{ts,tsx,js,jsx,py,go}' --type src.
4. For each flag, check evaluation telemetry (provider's "last evaluated" or local logs) over the last 30 days. Zero evaluations -> cold; >95% one-side -> stable-on or stable-off.
5. Decide per flag:
   • cold and zero call sites -> delete-from-provider (already orphaned).
   • cold with call sites -> verify-then-delete (might be in dead code).
   • stable-on -> promote-on (delete false branch in code; flag stays available for emergency).
   • stable-off -> sunset (delete true branch and the flag).
   • mixed evaluation but old -> decide-direction; surface to product owner.
6. For each promote-on / sunset, generate a code patch: an AST transform replacing if (flag('x')) { A } else { B } with A or B.
7. For each plan, list the call sites the patch will touch and a rollback path.
8. Compose a markdown plan with one section per flag.

Output

flag-cleanup-plan.md with the per-flag plan, call-site listings, and patch summaries. Plus a patches/<flag>.diff per actionable flag. Stdout prints counts per decision class.

Verification

For each promote-on patch, confirm the if-branch and else-branch are functionally distinct (otherwise the flag was already a no-op). Run the patched test suite; an unchanged result is the expected outcome since we're removing a code path that was never exercised. Audit the provider after deletion to confirm the flag's gone (curl ... 404).

Edge cases

• Flags evaluated dynamically (flag(name + suffix)): cannot be matched statically; surface as dynamic-evaluation, manual review.
• Flags wired to multiple environments with different states: assess per-env, recommend per-env action.
• Flags used as kill-switches (deliberately stable-on but kept for emergency): mark as keep-as-killswitch and exclude from cleanup.
• Flags whose owner left the company: list under "ownership gap" before any deletion suggestion.