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
