Feature Flag Rollout Approval Prompt for Release Agents

This prompt is for release engineering teams that use AI agents to manage progressive feature delivery. Its job is to generate a structured, human-readable approval request before a feature flag's exposure is expanded. The ideal user is a release manager, product engineer, or platform operator who receives an AI agent's proposal to increase a rollout percentage and must approve or deny the action based on a complete, standardized brief. The prompt forces the agent to articulate the feature description, target audience percentage, success metrics, monitoring dashboard links, and explicit rollback criteria. This is not a prompt for creating feature flags, toggling them directly, or analyzing their performance in isolation; it is specifically for the approval checkpoint before exposure expansion.

Use this prompt when an AI release agent proposes a rollout percentage increase inside a CI/CD pipeline, a release management chatbot, or an internal platform where feature flag changes require a gated approval step. The required context includes the feature flag identifier, the current rollout percentage, the proposed new percentage, the target audience segment, links to relevant monitoring dashboards, and the success metrics that define a healthy rollout. Without this context, the agent cannot produce a useful approval request. The prompt is designed to be wired into a system where the agent has access to the feature flag management tool's API, the observability platform, and the incident management tool, so it can pull live data into the approval request rather than relying on stale or hallucinated information.

Do not use this prompt for general-purpose feature flag management, for one-click approval automation without human review, or for low-risk flag changes where a full approval brief adds unnecessary friction. It is also not suitable for environments where the agent lacks access to real monitoring data, as the prompt will then generate plausible but unverified metrics and dashboard links. In high-risk domains, always pair this prompt with a human-in-the-loop step that requires explicit confirmation before the flag configuration is updated. The next step after reading this section is to copy the prompt template, adapt the placeholders to your feature flag platform and observability tools, and build the validation harness that checks for missing monitoring hooks and undefined rollback triggers before the approval request is sent to a human.

This prompt template is designed to be placed directly into your release agent's system instructions. It forces the model to act as a cautious release engineer, producing a structured approval request before any feature flag audience expansion. The agent will not proceed without defining the target percentage, success metrics, monitoring links, and explicit rollback criteria. Use this as a blocking step in a multi-turn agent workflow where the output must be reviewed and approved by a human before any actual flag configuration change is executed.

markdownCopy
You are a release agent responsible for generating feature flag rollout approval requests. Your output must be reviewed and explicitly approved by a human before any flag configuration is changed. You do not have the ability to modify feature flags yourself.

Before generating an approval request, you must verify that the following information is available. If any required field is missing, you must stop and request the missing information from the user rather than proceeding with incomplete data.

## Required Inputs
- [FEATURE_FLAG_NAME]: The unique key or name of the feature flag.
- [FEATURE_DESCRIPTION]: A clear, non-technical summary of what the feature does and its user-facing impact.
- [TARGET_AUDIENCE_PERCENTAGE]: The proposed percentage of users to expose to the feature (1-100).
- [SUCCESS_METRICS]: A list of specific, measurable criteria that define a successful rollout (e.g., "p99 latency < 200ms", "error rate < 0.1%", "conversion rate increase > 2%").
- [MONITORING_DASHBOARD_LINK]: A direct URL to the dashboard where these metrics can be observed in real-time.
- [ROLLBACK_CRITERIA]: A list of explicit conditions that will trigger an immediate rollback (e.g., "p99 latency exceeds 500ms for 5 minutes", "error rate exceeds 1%", ">5 user complaints about data loss").
- [ROLLBACK_PLAN]: The step-by-step procedure to revert the flag to 0% and verify the rollback.
- [APPROVAL_CHAIN]: The named individuals or roles required to approve this rollout (e.g., "on-call SRE, product manager for checkout").

## Output Schema
Generate a JSON object with the following structure. Do not include any text outside the JSON object.
{
  "approval_request_id": "string",
  "status": "pending_approval",
  "feature_flag": {
    "name": "[FEATURE_FLAG_NAME]",
    "description": "[FEATURE_DESCRIPTION]",
    "target_audience_percentage": [TARGET_AUDIENCE_PERCENTAGE],
    "current_audience_percentage": [CURRENT_AUDIENCE_PERCENTAGE]
  },
  "rollout_plan": {
    "success_metrics": ["[SUCCESS_METRIC_1]", "[SUCCESS_METRIC_2]"],
    "monitoring_dashboard": "[MONITORING_DASHBOARD_LINK]",
    "observation_window_minutes": [OBSERVATION_WINDOW_MINUTES]
  },
  "safety_checks": {
    "rollback_criteria": ["[ROLLBACK_CRITERION_1]", "[ROLLBACK_CRITERION_2]"],
    "rollback_plan": "[ROLLBACK_PLAN]",
    "is_rollback_plan_tested": [true/false]
  },
  "approval_required_from": ["[APPROVER_1]", "[APPROVER_2]"],
  "generated_at": "[CURRENT_TIMESTAMP]"
}

## Constraints
- If [TARGET_AUDIENCE_PERCENTAGE] is greater than 10 and this is the first rollout, add a warning to the `safety_checks` field recommending a smaller initial canary.
- If [MONITORING_DASHBOARD_LINK] is missing or invalid, set `status` to `blocked` and provide a reason.
- If [ROLLBACK_CRITERIA] is empty or contains only vague statements like "if something goes wrong," set `status` to `blocked` and request specific, measurable criteria.
- Never generate an approval request with `status: "approved"`. The status must always be `pending_approval` or `blocked`.

To adapt this prompt, replace the square-bracket placeholders with data from your application's feature flag management system (e.g., LaunchDarkly, Split) and your observability stack (e.g., Datadog, Grafana). The [CURRENT_TIMESTAMP] should be generated by your application at call time. In a production harness, the JSON output from this prompt should be validated against the schema before being surfaced in a review UI. If the model returns status: blocked, your application should prevent any downstream flag change and surface the blocking reason to the user. This prompt is a gating mechanism, not a suggestion box.

This prompt is designed to sit at a critical control point in a release pipeline, not as a standalone chatbot interaction. The most reliable integration pattern is to invoke the LLM as a structured approval generator immediately after a feature flag configuration change is proposed but before it is applied. The application layer should supply the required inputs—feature name, target audience percentage, success metrics, monitoring links, and rollback criteria—from the release management system or feature flag service (e.g., LaunchDarkly, Split, or an internal platform). The prompt's output should be treated as a draft approval request that requires explicit human signoff before the flag change is executed. Do not use this prompt to auto-approve rollouts; its purpose is to create a consistent, auditable checkpoint that forces a human to review the evidence.

Wire the prompt into a release agent or CI/CD plugin using a three-step harness: (1) Input Assembly: Collect the required fields from the feature flag system's API or a deployment manifest. Validate that all required fields are non-empty and that monitoring links are reachable (HTTP 200 check). If any required field is missing, abort and notify the release team before calling the LLM. (2) LLM Invocation: Call the model with the prompt template, using a low-temperature setting (0.0–0.2) to maximize consistency. Implement a retry wrapper with up to three attempts, checking that the output is valid JSON matching the expected schema. If the model fails to produce valid JSON after three retries, log the failure, capture the raw output for debugging, and escalate to the release team with a clear error message. (3) Human Review Gate: Render the generated approval request in a review interface (Slack, email, or a custom dashboard) with explicit Approve/Reject buttons. The approval action must be logged with the reviewer's identity, timestamp, and the full approval payload. Only after confirmation should the feature flag change be applied. For high-risk rollouts (e.g., targeting more than 10% of users or affecting payment flows), consider requiring a second approver.

Model choice matters here. Use a model with strong instruction-following and JSON output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or a fine-tuned variant if your organization has specific formatting conventions. Avoid smaller or older models that may omit required fields or hallucinate monitoring links. If your release pipeline has strict latency requirements, pre-warm the model endpoint and set a timeout of 10 seconds. For auditability, log every invocation: the input parameters, the generated approval payload, the validator result, and the final human decision. This creates a traceable record for compliance reviews and post-incident analysis. Never bypass the human review step for rollouts that touch production users, even if the model's output passes all automated validation checks.

Common integration pitfalls to avoid: (1) Allowing the LLM to generate the success metrics or rollback criteria from scratch—these must come from the release team, not the model, to prevent hallucinated safety guarantees. (2) Skipping the monitoring link reachability check, which can lead to a false sense of security if dashboards are broken. (3) Using the prompt in a fully automated loop without a human gate, which defeats the purpose of an approval workflow. (4) Failing to version the prompt template alongside the release agent code, making it difficult to debug approval quality regressions. Treat this prompt like a schema contract: version it, test it with golden examples, and monitor its output quality over time.