The prompt
Score 10 of 10, Excellent
Use it when A feature is ready to ship and you want to release it to a growing share of users, with checks and a rollback trigger at each stage.
- {{approvers}}
- {{feature}}
- {{flag_tool}}
- {{success_metric}}
- {{monitoring}}
- {{exclusions}}
- {{deadline}}
Full prompt and why it works
Prompt
# Role You help a product team plan a gradual release of a finished feature behind a feature flag. # Goal Write a staged rollout plan for the feature below, for {{approvers}} to sign off before the first stage, so that a problem reaches as few users as possible and everyone knows in advance when to pause or roll back. # Success criteria - Every stage has an audience, a minimum duration, the metrics to check, and a pause or rollback trigger written as a number. - Guardrail metrics (errors, performance, support contacts, revenue) are watched alongside the feature's own success metric. - Each stage names who decides to move on. # Constraints - Use only the metrics, tools and audiences in the context. Do not invent dashboards, metric names or baselines; where a trigger needs a baseline the context does not give, write [baseline needed: metric] instead. - Do not plan a stage for users the context says must be excluded, such as regulated accounts or customers in a contract freeze. - Keep to the smallest number of stages that still limits risk, usually 3 to 5 stages. # Output Use a Markdown heading for each part. 1. Stages: a table with the columns Stage, Audience (share or named group), Minimum duration, Move on when, Pause or roll back when, Decides. 2. Guardrails: each metric with its baseline and the change that triggers a pause. 3. Rollback: the steps to turn the flag off, what happens to data users created while it was on, and who tells whom. 4. Communication: who hears about each stage (support, sales, customers), and when. 5. Open questions. For example, the form of one trigger: "Pause if checkout errors rise above 0.5% of sessions for 30 minutes, measured against the 7-day baseline." This shows the form only; use the real metrics. # Stop rules If the context does not say whether turning the flag off is safe for data created while it was on, list it first under Open questions and mark the rollback section "unconfirmed", because a rollback that loses customer data is worse than the bug it fixes. # Context Feature: {{feature}} Flag tool and how targeting works: {{flag_tool}} Success metric: {{success_metric}} Monitoring available (dashboards, alerts, metrics): {{monitoring}} Users or accounts to exclude: {{exclusions}} Launch deadline, if any: {{deadline}}
Variables
- {{approvers}}
- Who signs off the plan, for example "the PM, the engineering lead and the on-call manager".
- {{feature}}
- What the feature does and what it changes for users, in a few sentences.
- {{flag_tool}}
- Your feature flag tool and how you can target users, for example "LaunchDarkly, by account ID, plan or percentage".
- {{success_metric}}
- The metric that shows the feature works, with its definition.
- {{monitoring}}
- Dashboards, alerts and metrics you can watch during the rollout, with current baselines if you know them.
- {{exclusions}}
- Users or accounts that must not get it early, or "none".
- {{deadline}}
- The date it must be fully live, or "none".
Why it works
- What good looks like. Every stage has a number that moves it on and another that pauses it, agreed before the first user sees the feature.
- If unsure. If it is unclear whether turning the flag off is safe for data created while it was on, the rollback is marked unconfirmed and raised first.
- Layout. Markdown sections in the order OpenAI recommends, with the rollout details last as context.