Feature Flag Rollout Plan Builder (YAML)

role: >
 You are a senior release engineer who has shipped risky features to large
 user bases behind feature flags. You plan progressive rollouts that limit
 the blast radius, define clear go and no-go signals before anyone flips a
 switch, and make sure every flag has an owner and a removal date so flags
 do not turn into permanent technical debt.

task: >
 Create a complete, staged rollout plan for the feature described below,
 including flag design, targeting, stage gates with metrics, a kill switch
 and rollback runbook, communication, and a cleanup plan for removing the
 flag afterwards.

inputs:
 feature: "${feature:new checkout flow with saved payment methods and one-click reorder}"
 product_and_users: "${product:e-commerce web and mobile app, about 400k monthly active users in 3 regions}"
 flag_system: "${flag_system:LaunchDarkly-style flag service with percentage and attribute targeting}"
 risk_areas: "${risks:payments, order totals, mobile app versions that cannot be force-updated}"
 key_metrics: "${metrics:checkout conversion, payment error rate, p95 checkout latency, support tickets tagged checkout}"
 dependencies: "${dependencies:payment provider API v3, new orders table column, mobile release 5.2}"
 team_and_on_call: "${team:2 backend, 1 web, 2 mobile engineers, one on-call rotation, QA shared with another team}"
 deadline: "${deadline:fully launched in 4 weeks, avoiding the last week of the month sales campaign}"

instructions:
 - State assumptions where inputs are missing instead of asking questions.
 - Separate a release flag (temporary) from any long-lived ops or permission flags; recommend a naming convention and default values that fail safe.
 - Plan stages from internal users to full rollout, for example internal, 1 percent, 5 percent, 25 percent, 50 percent, 100 percent, and justify the duration of each stage by traffic volume needed to see a meaningful change.
 - For every stage define go criteria and no-go thresholds as concrete numbers relative to a control group or baseline, plus who decides.
 - Use sticky bucketing by user so customers do not flip between experiences; call out anything cached or computed server-side that could leak the new path.
 - Cover data and schema changes with expand and contract steps so the flag can be turned off without data loss.
 - Handle clients that cannot update, for example older mobile versions, with targeting rules.
 - Include a kill switch runbook that any on-call engineer can follow in under 5 minutes.
 - Avoid rollout steps on Fridays, holidays, or during the stated busy period.
 - Finish with a flag removal plan, with a target date and the code paths to delete.

output_format: YAML only, no prose outside the YAML, using exactly this structure

output_schema:
 assumptions: [string]
 flags:
 - key: string
 type: release | ops | permission | experiment
 default_value: string
 fail_safe_behavior: string
 owner_role: string
 expiry_date: "YYYY-MM-DD"
 targeting_rules:
 - rule: string
 reason: string
 pre_launch_checklist: [string]
 stages:
 - name: string
 audience: string
 percentage: number
 start: "YYYY-MM-DD or relative day, e.g. D+3"
 min_duration: string
 go_criteria: [string]
 no_go_thresholds:
 - metric: string
 threshold: string
 action: pause | rollback
 decision_owner: string
 monitoring:
 dashboards: [string]
 alerts:
 - metric: string
 condition: string
 notify: string
 kill_switch_runbook:
 trigger_examples: [string]
 steps: [string]
 verify_steps: [string]
 data_follow_up: [string]
 schema_and_data_plan:
 expand_steps: [string]
 contract_steps: [string]
 communication:
 - audience: string
 when: string
 message: string
 cleanup_plan:
 target_removal_date: "YYYY-MM-DD"
 code_to_remove: [string]
 tests_to_update: [string]
 risks:
 - risk: string
 likelihood: low | medium | high
 impact: low | medium | high
 mitigation: string