Feature Flag Cleanup and Toggle Debt Runbook Builder

Create a runbook for auditing stale feature flags, classifying toggle debt, safely removing flags, testing behavior, and preventing future flag sprawl.

Prompt Template

You are a senior release engineer helping a team reduce feature flag and toggle debt safely. Build a cleanup runbook for:

Application or service: [name and purpose]
Stack and repo structure: [language, framework, monorepo, services, mobile/web/backend]
Feature flag system: [LaunchDarkly, Statsig, ConfigCat, Unleash, homemade, environment variables]
Flag inventory available: [flag names, creation dates, owners, rollout %, environments, usage data]
Known stale flags: [list or paste export]
Flag types: [release, experiment, ops, permission, kill switch, migration, entitlement]
Current risk: [unclear behavior, complex conditionals, test gaps, customer-specific overrides]
Ownership model: [team owners, no owners, product managers, platform team]
Testing setup: [unit, integration, E2E, snapshots, staging, canary, no tests]
Deployment process: [CI/CD, release trains, feature branches, mobile app store constraints]
Observability: [logs, metrics, error tracking, flag evaluation events]
Compliance or audit needs: [SOX, change control, regulated customers, enterprise approvals]
Cleanup goal and timeline: [one sprint, quarterly hygiene, pre-migration, release hardening]

Create:
1. Flag inventory fields and classification rules for active, stale, risky, permanent, and unknown flags.
2. Decision tree for remove, keep, convert to configuration, transfer ownership, or investigate.
3. Risk scoring model based on blast radius, environment usage, customer targeting, code complexity, and test coverage.
4. Safe removal workflow for code paths, tests, configuration, dashboards, docs, and flag platform cleanup.
5. Test plan for both old and final behavior before deleting conditionals.
6. Rollout and rollback plan for removing high-risk flags.
7. Pull request checklist and reviewer guidance.
8. Observability checks after deploy, including metrics that should not move.
9. Ownership and lifecycle policy to prevent future toggle debt.
10. Example cleanup ticket template with acceptance criteria.

Be conservative. Do not recommend deleting a flag until its intended final behavior, owner, and customer impact are understood.

Example Output

Toggle Debt Cleanup Runbook

Classification

| Flag | Type | Rollout | Owner | Risk | Action |

|---|---|---:|---|---|---|

| checkout_v2_enabled | Release | 100% prod | Payments | Medium | Remove old checkout path after tests pass |

| beta_reporting_export | Entitlement | Targeted customers | Analytics | High | Keep and document as product entitlement |

| kill_cache_reads | Ops | Off | Platform | High | Keep as kill switch with owner and runbook |

Removal Workflow

1. Confirm final behavior with product and engineering owner.

2. Add or update tests that assert the final always-on behavior.

3. Remove the conditional branch and dead code.

4. Delete unused config, dashboards, experiment reports, and docs references.

5. Deploy behind normal release process and watch checkout conversion, error rate, and support contacts for 48 hours.

PR Acceptance Criteria

The PR includes the flag name, final behavior, screenshots or logs proving 100% rollout, tests updated, rollback plan, and the flag platform cleanup task.

Tips for Best Results

  • 💡Export flag metadata first; stale flags are risky when ownership and targeting are unknown.
  • 💡Keep operational kill switches separate from temporary release flags.
  • 💡Write tests for the final behavior before deleting the alternate branch.
  • 💡Make flag retirement part of the original feature definition of done.