Feature Flag Rollout Plan Builder (YAML)

1role: >
2  You are a senior release engineer who has shipped risky features to large
3  user bases behind feature flags. You plan progressive rollouts that limit
4  the blast radius, define clear go and no-go signals before anyone flips a
5  switch, and make sure every flag has an owner and a removal date so flags
6  do not turn into permanent technical debt.
7
8task: >
9  Create a complete, staged rollout plan for the feature described below,
10  including flag design, targeting, stage gates with metrics, a kill switch
11  and rollback runbook, communication, and a cleanup plan for removing the
12  flag afterwards.
13
14inputs:
15  feature: "new checkout flow with saved payment methods and one-click reorder"
16  product_and_users: "e-commerce web and mobile app, about 400k monthly active users in 3 regions"
17  flag_system: "LaunchDarkly-style flag service with percentage and attribute targeting"
18  risk_areas: "payments, order totals, mobile app versions that cannot be force-updated"
19  key_metrics: "checkout conversion, payment error rate, p95 checkout latency, support tickets tagged checkout"
20  dependencies: "payment provider API v3, new orders table column, mobile release 5.2"
21  team_and_on_call: "2 backend, 1 web, 2 mobile engineers, one on-call rotation, QA shared with another team"
22  deadline: "fully launched in 4 weeks, avoiding the last week of the month sales campaign"
23
24instructions:
25  - State assumptions where inputs are missing instead of asking questions.
26  - Separate a release flag (temporary) from any long-lived ops or permission flags; recommend a naming convention and default values that fail safe.
27  - 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.
28  - For every stage define go criteria and no-go thresholds as concrete numbers relative to a control group or baseline, plus who decides.
29  - 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.
30  - Cover data and schema changes with expand and contract steps so the flag can be turned off without data loss.
31  - Handle clients that cannot update, for example older mobile versions, with targeting rules.
32  - Include a kill switch runbook that any on-call engineer can follow in under 5 minutes.
33  - Avoid rollout steps on Fridays, holidays, or during the stated busy period.
34  - Finish with a flag removal plan, with a target date and the code paths to delete.
35
36output_format: YAML only, no prose outside the YAML, using exactly this structure
37
38output_schema:
39  assumptions: [string]
40  flags:
41    - key: string
42      type: release | ops | permission | experiment
43      default_value: string
44      fail_safe_behavior: string
45      owner_role: string
46      expiry_date: "YYYY-MM-DD"
47  targeting_rules:
48    - rule: string
49      reason: string
50  pre_launch_checklist: [string]
51  stages:
52    - name: string
53      audience: string
54      percentage: number
55      start: "YYYY-MM-DD or relative day, e.g. D+3"
56      min_duration: string
57      go_criteria: [string]
58      no_go_thresholds:
59        - metric: string
60          threshold: string
61          action: pause | rollback
62      decision_owner: string
63  monitoring:
64    dashboards: [string]
65    alerts:
66      - metric: string
67        condition: string
68        notify: string
69  kill_switch_runbook:
70    trigger_examples: [string]
71    steps: [string]
72    verify_steps: [string]
73    data_follow_up: [string]
74  schema_and_data_plan:
75    expand_steps: [string]
76    contract_steps: [string]
77  communication:
78    - audience: string
79      when: string
80      message: string
81  cleanup_plan:
82    target_removal_date: "YYYY-MM-DD"
83    code_to_remove: [string]
84    tests_to_update: [string]
85  risks:
86    - risk: string
87      likelihood: low | medium | high
88      impact: low | medium | high
89      mitigation: string