Claude Code Prompt to Implement a Feature Flag System

What this prompt does

This prompt turns Claude Code into a feature-flag engineer that builds the whole system end to end, not just the on/off check. You hand it a feature name, your framework, and a backend, and it scaffolds the flag service, writes the flag definition with targeting rules, instruments the integration points you name, and wires a kill switch for instant disable — the ten numbered deliverables run from the service layer all the way to unit tests for both flag states, including the admin UI or API you'll use to manage flags once they're live.

It works because it forces the parts teams usually skip. Most flag code rots: a flag ships, the rollout hits 100%, and the dead if/else lives forever. By baking in a cleanup checklist, a lifecycle policy with a max_age, a naming convention, and a documentation template, the prompt treats every flag as temporary by default. Demanding per-variant metrics and tests for both states also keeps Claude from generating the happy-path-only instrumentation that makes flags impossible to measure or safely remove.

When to use it

• Shipping a risky feature behind a progressive rollout, starting at a low initial_rollout% and ramping with a kill switch ready.
• Running an A/B test where you need clean per-variant metric tracking, not just a boolean toggle.
• Adding flags to a codebase that has none, and you want a convention and lifecycle policy from day one.
• Decoupling deploy from release so you can merge to main without exposing unfinished work.
• Targeting a specific user segment first — internal staff, beta cohort, a single region — before going wide.
• Auditing flag debt: generate the cleanup checklist for flags that have outlived their max_age.

Example output

src/featureflags/FlagService.php   # LaunchDarkly-backed provider, getVariant(flag, user)
flags/checkout_v2_redesign.yaml    # boolean, 10% rollout, segment: [internal, beta-eu]
  → instrumented: CheckoutController@show, cart.blade.php, OrderObserver

Kill switch:  flag('checkout_v2_redesign')->disable()   // bypasses cache, instant
Metrics:      conversion_rate, p95_latency  tracked per variant → StatsD
Management:   GET/PATCH /admin/flags  (toggle, rollout %, segments)

Cleanup checklist (max_age: 30d, created 2026-06-19):
  [ ] Remove 3 code paths in CheckoutController, OrderObserver
  [ ] Delete flag definition + tests
Tests: FlagOnTest, FlagOffTest, SegmentTargetingTest  (PASS)

Pro tips

• Set initial_rollout to 0%, not 5%. Ship the flag fully off, verify the kill switch and metrics fire in production, then ramp. A flag you can't turn off safely is worse than no flag.
• Match flag_backend to your real constraints: a config/DB backend is fine for kill switches, but percentage rollouts and segments need a backend with consistent hashing (same user → same variant), so name LaunchDarkly, Unleash, or Flagsmith explicitly.
• Make metrics a guardrail metric plus a goal metric (e.g. p95_latency and conversion_rate). One number can't tell you if the new variant won without quietly breaking something else.
• Treat max_age as a hard expiry, not a suggestion — pair this prompt with a scheduled "expired flags" report so the cleanup checklist actually gets executed instead of bookmarked.
• Pin a strict flag_naming_convention (e.g. team_feature_purpose) up front; once you have 50 flags, an inconsistent namespace makes targeting rules and cleanup a guessing game.