Feature Flag Lifecycle Management Prompt

This prompt is for platform engineering teams that own feature flag infrastructure and need to prevent flag accumulation from becoming a reliability and cognitive load problem. The job-to-be-done is a structured lifecycle audit: given a list of flags, their metadata, and deployment history, the prompt produces a phase assessment (birth, ramp, full rollout, cleanup, sunset) for each flag, identifies ownership handoff gaps, and flags stale or abandoned flags that should be scheduled for removal. The ideal user is a staff engineer, platform architect, or release engineering lead who understands the flagging system's operational semantics and can provide accurate flag metadata as input.

Use this prompt when your organization has more than a handful of long-lived feature flags, when flags persist in code months after full rollout, or when ownership of flags has shifted across teams without explicit handoff. The prompt is designed for periodic hygiene reviews—weekly, per-sprint, or pre-release—rather than real-time flag evaluation during request processing. It assumes you can supply a structured input with flag names, creation dates, rollout percentages, owning teams, last-modified timestamps, and any associated cleanup tickets. The output is a lifecycle stage classification and a set of actionable recommendations, not a runtime flag evaluation decision.

Do not use this prompt for runtime flag evaluation, for flag creation workflows, or as a substitute for a flag management UI. It does not make targeting decisions, does not validate flag code, and does not replace your feature flag service's admin panel. If your flag data is incomplete—missing ownership history, no last-modified dates, or unclear rollout status—the prompt will produce low-confidence assessments that require manual verification. For regulated environments where flag removal has compliance implications, always pair the prompt's output with a human review step and evidence grounding before scheduling cleanup. The next section provides the copy-ready prompt template you can adapt to your flag inventory format.

This prompt template is the core engine for generating a Feature Flag Lifecycle Management review. It is designed to be copied directly into your prompt library or orchestration layer. The template uses square-bracket placeholders, such as [FLAG_CATALOG] and [PLATFORM_CONTEXT], which your application must populate with real data before sending the request to the model. The structure forces the model to act as a platform architect auditing a flag's journey from creation to deprecation, rather than just describing what feature flags are.

textCopy
You are a platform architect reviewing the lifecycle of feature flags in a production system. Your goal is to produce a structured audit that identifies risks, ownership gaps, and stale flags across the entire lifecycle: birth, ramp, full rollout, cleanup, and sunset.

## Flag Catalog
[FLAG_CATALOG]

## Platform Context
- Flagging system used: [FLAG_SYSTEM]
- Deployment cadence: [DEPLOYMENT_CADENCE]
- Team ownership model: [OWNERSHIP_MODEL]

## Review Constraints
[CONSTRAINTS]

## Output Schema
Return your analysis as a JSON object with the following structure:
{
  "flags": [
    {
      "flag_name": "string",
      "lifecycle_stage": "birth | ramping | full_rollout | cleanup_pending | sunset",
      "created_date": "YYYY-MM-DD",
      "owner_team": "string",
      "target_removal_date": "YYYY-MM-DD | null",
      "risk_score": "low | medium | high | critical",
      "findings": [
        {
          "category": "ownership_gap | stale_flag | missing_cleanup_plan | ramp_duration | kill_switch_missing | other",
          "severity": "low | medium | high | critical",
          "description": "string",
          "recommendation": "string"
        }
      ]
    }
  ],
  "systemic_risks": [
    {
      "pattern": "string",
      "affected_flags": ["string"],
      "description": "string",
      "remediation": "string"
    }
  ],
  "summary": "string"
}

## Instructions
1. For each flag in the catalog, determine its lifecycle stage based on creation date, rollout percentage, and cleanup status.
2. Identify ownership handoff gaps where the creating team no longer owns the flag but no new owner is documented.
3. Flag any flag that has been at 100% rollout for more than [STALE_THRESHOLD_DAYS] days without a cleanup plan.
4. Check for missing kill switch configurations on ramping or fully rolled out flags.
5. Surface systemic patterns, such as a team consistently failing to deprecate flags.
6. If the risk level is [RISK_LEVEL] or higher, include a specific recommendation for immediate action.
7. Do not invent flag names, dates, or configurations. Only analyze the provided catalog.

To adapt this template for your environment, replace the placeholders with concrete data. For [FLAG_CATALOG], provide a structured list of flags, including their creation date, rollout percentage, owner, and targeting rules. The [STALE_THRESHOLD_DAYS] should be set to your organization's policy, such as 30 or 60 days. The [RISK_LEVEL] variable controls the sensitivity of the review; setting it to medium will generate actionable recommendations for more flags. After running the prompt, always validate the output JSON against the schema before piping the results into your cleanup automation or ticketing system.

This prompt is designed to be called by a platform automation system—such as a CI/CD pipeline, a flag management service, or an internal developer portal—not by a human copying and pasting into a chat window. The harness should supply the flag metadata, ownership records, and usage telemetry as structured inputs, then parse the model's output into actionable lifecycle recommendations. Because stale flags cause production incidents and technical debt accumulation, the harness must treat the model's output as advisory and route high-risk recommendations (e.g., flag removal, ownership transfer) through a human approval step before any automated action is taken.

The implementation should follow a validate → retry → review → act pattern. First, validate the model's output against a strict JSON schema that enforces required fields: flag_id, lifecycle_phase, recommended_action, risk_level, evidence, and deadline. If validation fails, retry once with the error message appended to the prompt context. If the retry also fails, log the failure and escalate to the flag owner. For recommendations with risk_level: high or actions like deprecate or remove, route to a human review queue with a pre-formatted approval payload. For low-risk actions like add_cleanup_task_to_backlog, the harness can auto-create a ticket in the team's backlog system. Use a model with strong JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize output consistency across runs.

Log every invocation with the flag ID, model version, input telemetry snapshot, raw output, validation result, and final action taken. This audit trail is essential for demonstrating flag hygiene governance to engineering leadership and for debugging cases where the model misclassifies a flag's lifecycle phase. Avoid wiring the prompt directly to a flag deletion API—the harness should always require explicit human approval for destructive actions. Start with a weekly batch job that processes all flags older than 30 days, then tighten the cadence as the team builds confidence in the model's recommendations and the review workflow.