Service Mesh Configuration Change Review Prompt

This prompt is designed for platform and SRE teams who need a structured, automated first pass at reviewing service mesh configuration changes before they reach a cluster. The core job-to-be-done is risk identification: turning a raw configuration diff into a report that highlights traffic policy modifications, mTLS enforcement changes, retry and timeout adjustments, and fault injection rules. The ideal user is a platform engineer or on-call reviewer who understands the mesh's control plane but needs help scaling their attention across frequent, high-impact configuration updates. The prompt assumes you are providing a unified diff or a structured representation of the change, along with the mesh platform name (Istio, Linkerd, or Consul) and the target namespace scope. Without these inputs, the blast radius analysis cannot accurately map which services and traffic paths are affected.

Use this prompt as a pre-merge gate in a CI/CD pipeline, as a structured input to a change advisory board (CAB) review, or as part of a pre-deployment checklist. In a CI/CD context, wire the prompt to run automatically when a PR modifies files in a mesh config directory. The output should block the merge if it contains high-severity findings with a blast radius that exceeds a predefined threshold. For CAB reviews, the structured risk report serves as a consistent agenda item, ensuring reviewers focus on the most dangerous changes first. For pre-deployment checklists, the report's blast radius analysis helps the on-call engineer decide which service dashboards to monitor during the rollout. In all cases, the prompt is a decision-support tool, not a decision-maker; it reduces the cognitive load of parsing diffs but does not replace human judgment for high-risk changes.

Do not use this prompt for real-time traffic debugging, for reviewing application-level code changes, or for generating the fix itself. It is not designed to analyze live metrics, traces, or logs, and it will not correctly interpret changes to application business logic that happen to be deployed behind the mesh. If you need to understand why a specific request failed in production, use an observability prompt or a log analysis playbook instead. If you need to generate a corrected configuration, pair this review prompt with a separate remediation prompt that takes the risk report as input. Finally, if your mesh configuration is managed entirely through a custom operator that generates EnvoyFilter or equivalent resources dynamically, this prompt may produce false positives on intermediate representations; in that case, run the review on the operator's source-of-truth input, not the generated output.

This template is designed to be copied directly into your AI harness, CI/CD pipeline, or review tool. It expects a configuration diff, the target mesh platform, and your organization's specific review constraints. Replace each square-bracket placeholder with your actual values before execution. The prompt enforces a structured output schema so that downstream automation can parse findings, route them to the correct team, and block deployment if critical risks are detected.

textCopy
You are a service mesh configuration reviewer for a platform engineering team. Your task is to analyze a configuration change diff for [MESH_PLATFORM] (e.g., Istio, Linkerd, Consul) and produce a structured risk report.

## INPUT
[MESH_CONFIG_DIFF]

## CONTEXT
- Mesh Platform: [MESH_PLATFORM]
- Environment: [ENVIRONMENT]
- Services Affected: [SERVICE_LIST]
- Change Author: [AUTHOR]
- Change Ticket: [TICKET_REFERENCE]

## CONSTRAINTS
- [ORGANIZATIONAL_POLICIES]
- [REVIEW_REQUIREMENTS]
- [COMPLIANCE_STANDARDS]

## TASK
Analyze the configuration diff and identify risks in these categories:
1. Traffic Policy Modifications (routing, load balancing, circuit breaking)
2. mTLS Enforcement Changes (authentication policy, peer authentication)
3. Retry/Timeout Configuration Impact (resilience, cascading failure risk)
4. Fault Injection Risk (deliberate fault injection for testing)
5. Blast Radius Analysis (which services and users are affected)
6. Security Posture Changes (authorization policy, ingress/egress rules)

For each finding, provide:
- Severity (CRITICAL, HIGH, MEDIUM, LOW)
- Category from the list above
- Affected Resource (specific config object name)
- Description of the change and its risk
- Potential impact on dependent services
- Recommended action (APPROVE, BLOCK, REQUIRE_MANUAL_REVIEW, SUGGEST_ALTERNATIVE)
- Evidence (quote the relevant lines from the diff)

## OUTPUT_SCHEMA
{
  "review_summary": {
    "overall_risk": "LOW|MEDIUM|HIGH|CRITICAL",
    "total_findings": <integer>,
    "critical_findings": <integer>,
    "recommendation": "APPROVE|BLOCK|REQUIRE_CHANGES"
  },
  "findings": [
    {
      "id": "F-<integer>",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "category": "traffic_policy|mtls|retry_timeout|fault_injection|blast_radius|security",
      "resource": "<config object name>",
      "description": "<clear explanation of the change and risk>",
      "impact": "<what breaks, degrades, or is exposed>",
      "affected_services": ["<service name>"],
      "recommendation": "APPROVE|BLOCK|REQUIRE_MANUAL_REVIEW|SUGGEST_ALTERNATIVE",
      "evidence": "<quoted lines from diff>"
    }
  ],
  "blast_radius": {
    "directly_affected_services": ["<service name>"],
    "indirectly_affected_services": ["<service name>"],
    "user_facing_impact": "<description or null>"
  }
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

If the diff contains destructive changes (e.g., removing mTLS enforcement, deleting authorization policies, or injecting faults into production traffic), flag them as CRITICAL and recommend BLOCK.

If you are uncertain about the blast radius or impact on a specific service, set recommendation to REQUIRE_MANUAL_REVIEW and explain what additional context is needed.

Do not invent services, dependencies, or impacts not evident in the diff. If the diff is incomplete or ambiguous, note this in the review_summary.

After copying the template, replace each square-bracket placeholder with concrete values. [MESH_CONFIG_DIFF] should contain the raw diff output from your GitOps pipeline or istioctl analyze report. [FEW_SHOT_EXAMPLES] should include 2-3 annotated examples of previous reviews showing correct severity assignment and blast radius reasoning. [ORGANIZATIONAL_POLICIES] should reference your team's specific rules, such as 'mTLS must remain STRICT in production' or 'fault injection requires director approval.' Wire this prompt into a CI check that parses the JSON output and blocks the pipeline if recommendation is BLOCK or if critical_findings is greater than zero. Always log the full prompt and response for auditability, and route REQUIRE_MANUAL_REVIEW findings to the mesh platform on-call rotation.

This prompt is designed to run as a gating step in a deployment pipeline or as part of a change advisory board (CAB) pre-review. The primary integration point is a pull request or merge request that contains service mesh configuration files—typically Istio DestinationRule, VirtualService, PeerAuthentication, or Sidecar resources. The application harness should extract the configuration diff, assemble the required context (namespace, affected services, current mesh topology snapshot), and invoke the model. The output is a structured risk report that downstream automation can parse to decide whether to block the merge, request human review, or allow the change to proceed with annotations.

For CI/CD integration, implement a pipeline step that: (1) runs git diff against the target branch to isolate mesh config changes; (2) queries the cluster's current mesh state via istioctl proxy-config or the control plane API to populate the [CURRENT_MESH_STATE] placeholder; (3) assembles the prompt with the diff, affected service list, and any organizational traffic policies as [CONSTRAINTS]; (4) calls the model with response_format set to the defined JSON schema; (5) validates the output against the schema and runs eval checks (blast radius completeness, severity consistency, false positive detection for comment-only changes); (6) on validation failure, retry once with the validation errors appended as feedback; (7) if the risk score exceeds a configurable threshold or any finding has severity CRITICAL, route to a human reviewer via your PR review system with the structured findings attached. Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to maximize consistency across runs.

Log every invocation with the prompt version, input diff hash, model response, validation result, and final disposition (auto-approved, flagged, blocked). This audit trail is essential for post-incident review and for tuning the risk thresholds over time. Avoid wiring this prompt directly to an auto-merge action without human review for any change touching DestinationRule subsets, PeerAuthentication mTLS mode, or fault injection policies—these have the highest blast radius and the model's analysis should be treated as an advisory signal, not an authorization decision. For teams using Linkerd or Consul, adapt the [CURRENT_MESH_STATE] assembly logic to query the respective control plane APIs, but the prompt's traffic policy reasoning remains structurally applicable.