GitOps Sync Status Verification Prompt

This prompt is for platform engineers and SRE teams who need a machine-readable verdict on whether a Kubernetes cluster has truly converged to its desired state after a GitOps sync operation. The job-to-be-done is closing a change window with confidence: you have run a sync via ArgoCD, Flux, or a similar controller, and you need to confirm that the live resources in the cluster match the declarations in Git before you mark the deployment as complete, trigger a downstream pipeline, or hand off to the next on-call shift. The prompt consumes raw diagnostic output—such as kubectl diff, argocd app diff, or flux get summaries—and produces a structured drift report with resource-level reconciliation status, severity classification, and explicit flags for resources that require manual intervention.

Use this prompt when an automated sync has reported success but you need independent verification that the cluster state is not just 'synced' according to the controller, but actually converged. This is critical for resources that are known to drift silently, such as ConfigMaps with external mutation, CRDs with late-binding defaults, or StatefulSets where pod readiness can mask spec divergence. The prompt is designed to be wired into a post-sync verification harness that runs automatically after every sync, producing a structured JSON report that can gate subsequent automation. Do not use this prompt for initial deployment validation, capacity planning, or security policy audits—those require different context windows and evaluation criteria. This prompt is specifically scoped to the narrow window between a GitOps sync trigger and the confirmation that the cluster reflects the intended state.

Before using this prompt, ensure you have captured the full diff or status output from your GitOps tool, including any error messages, resource manifests, and sync operation metadata. The prompt expects raw, unredacted output to make accurate severity classifications. If you are operating in a high-compliance environment, pair this prompt's output with a human review step for any resource flagged with a CRITICAL severity or a manual_intervention_required flag. The next section provides the copy-ready prompt template you can adapt to your specific toolchain and output schema requirements.

This prompt template is designed to be injected into your GitOps reconciliation pipeline immediately after a sync operation completes. It instructs the model to act as a reliability auditor, comparing the desired state declared in Git against the actual state observed in the cluster. The output is a structured drift report that flags resource-level discrepancies, assesses their severity, and recommends whether manual intervention is required. Use this template when you need a programmatic, evidence-backed verification step before declaring a sync successful.

textCopy
You are a GitOps reconciliation auditor. Your task is to verify that the live state of a Kubernetes cluster matches the desired state declared in a Git repository after a sync operation.

## Inputs
- [SYNC_LOG]: The raw output or summary log from the GitOps sync tool (e.g., ArgoCD, Flux).
- [DESIRED_STATE_MANIFESTS]: The full set of Kubernetes manifests from the target Git revision.
- [LIVE_STATE_SNAPSHOT]: A snapshot of the live cluster resources, obtained via `kubectl get all -o yaml` or an equivalent API call for the target namespace/scope.
- [SYNC_TOOL]: The name and version of the GitOps tool used (e.g., ArgoCD v2.8).

## Task
1. Parse the [SYNC_LOG] to identify the sync operation's reported status (Success, Failed, Unknown) and any resources it flagged.
2. Compare the [DESIRED_STATE_MANIFESTS] against the [LIVE_STATE_SNAPSHOT] for every resource. Check for differences in:
   - Resource existence (present in Git but missing in cluster, or vice versa).
   - Spec differences (e.g., replicas, image tags, environment variables, resource limits).
   - Metadata differences (e.g., labels, annotations that affect behavior).
   - Status conditions (e.g., `Available`, `Progressing`, `Degraded`).
3. For each discrepancy found, classify its severity:
   - **CRITICAL**: Causes an outage, data loss, or security violation.
   - **WARNING**: Deviates from intent but does not cause immediate failure (e.g., wrong replica count within tolerance, missing non-essential label).
   - **INFO**: Cosmetic or non-functional difference.
4. Identify any resources that are in a `Progressing` or `Degraded` state, even if their spec matches Git, as these indicate an operational issue.

## Output Format
Return a single JSON object conforming to this schema:
{
  "sync_operation_status": "string (Success|Failed|Unknown)",
  "overall_drift_detected": "boolean",
  "resources_checked": "integer",
  "drift_report": [
    {
      "resource_kind": "string",
      "resource_name": "string",
      "resource_namespace": "string",
      "discrepancy_type": "string (MissingInCluster|ExtraInCluster|SpecDiff|MetadataDiff|StatusIssue)",
      "desired_state": "string (excerpt from Git manifest)",
      "live_state": "string (excerpt from cluster snapshot)",
      "severity": "string (CRITICAL|WARNING|INFO)",
      "human_intervention_required": "boolean",
      "remediation_hint": "string (brief, actionable suggestion)"
    }
  ],
  "manual_intervention_flags": [
    {
      "resource_identifier": "string (kind/namespace/name)",
      "reason": "string (why automation cannot safely resolve this)"
    }
  ],
  "summary": "string (a concise, human-readable summary of the verification outcome)"
}

## Constraints
- Do not hallucinate resources. Only report discrepancies you can cite with evidence from the provided inputs.
- If the [SYNC_LOG] indicates a failure but you cannot find a specific resource discrepancy, set `overall_drift_detected` to `true` and flag the sync operation itself as requiring human intervention.
- For any discrepancy classified as CRITICAL, `human_intervention_required` must be `true`.
- If no discrepancies are found, `drift_report` should be an empty array and `overall_drift_detected` should be `false`.

To adapt this template for your environment, replace the square-bracket placeholders with data from your pipeline. The [SYNC_LOG] can be piped directly from argocd app sync or flux reconcile output. The [DESIRED_STATE_MANIFESTS] should be the raw YAML from the commit SHA that triggered the sync. The [LIVE_STATE_SNAPSHOT] is best obtained via a post-sync hook that runs kubectl get for the target resources and captures the output. If your sync tool provides a structured diff (e.g., ArgoCD's diff result), you can pass that as additional context to reduce the model's comparison workload and improve accuracy. For high-risk production clusters, always route the manual_intervention_flags array to a human review queue before taking any automated remediation action.

The GitOps Sync Status Verification Prompt is designed to be called programmatically after a kubectl apply or an Argo CD/Flux sync operation completes. It should not be a one-off chat interaction. Instead, embed it in a post-sync hook, a CI/CD pipeline stage, or a Kubernetes controller's reconciliation loop. The prompt expects structured input containing the intended Git state (the desired manifest) and the live cluster state (the output of kubectl get or an equivalent API call). The output is a machine-readable drift report, which your harness must parse and act upon.

To wire this into an application, build a thin orchestration layer that performs three steps: collect, invoke, and validate. First, collect the desired state from the Git repository at the specific commit SHA that triggered the sync. Second, collect the live state from the target cluster for the same set of resources, scoped by namespace and label selectors. Third, assemble the prompt by injecting these two JSON or YAML payloads into the [DESIRED_STATE] and [LIVE_STATE] placeholders. Use a model with strong JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) and set response_format to json_object with the defined [OUTPUT_SCHEMA]. On receiving the response, validate it against the schema immediately. If validation fails, implement a single retry with a repair prompt that includes the validation error. If the retry also fails, log the failure and escalate to a human operator via a [HUMAN_REVIEW_QUEUE].

The most critical implementation detail is handling large states. Do not pass the entire cluster state if the sync only touched a few resources. Your harness must filter the input to only the resources in the sync set. If the filtered state still exceeds the model's context window, implement a chunking strategy: split resources by kind or namespace, run the prompt in parallel for each chunk, and then merge the drift_report arrays. For high-risk environments, add a mandatory human approval gate before any automated rollback. The prompt's requires_manual_intervention flag should trigger a notification to the on-call channel, not an autonomous action. Log every invocation, including the input hashes, model response, and validation result, to create an audit trail for post-incident review.

Avoid wiring this prompt directly to a kubectl delete or terraform destroy command. The verification report is a diagnostic tool, not an auto-remediation engine. The next step after a drift detection should be to pause the pipeline, notify the platform team, and attach the structured drift report to an incident ticket. This preserves the human-in-the-loop safety boundary while giving engineers the precise, resource-level detail they need to decide between re-syncing, rolling back, or investigating a controller bug.