Pod Resource Limit and Request Change Review Prompt

This prompt is designed for platform engineers and SRE teams who need to review Kubernetes pod resource configuration changes before they reach production. It ingests a diff of CPU and memory request/limit modifications and produces a structured stability assessment that covers OOM kill risk, scheduling failure probability, cost impact, and Quality of Service (QoS) class transitions. Use this prompt in CI/CD pipelines, PR review workflows, or pre-deployment checklists where resource misconfiguration is a leading cause of node pressure, evictions, and unexpected cloud spend.

The prompt assumes you have a before-and-after resource specification, namespace context, and node pool information available. It does not replace load testing or live profiling, but it catches the configuration errors that cause incidents before they ship. Required inputs include the full resource diff showing old and new request/limit values, the target namespace, available node pool capacity ranges, and any organizational resource policies such as maximum allowed memory limits or required QoS tiers. Without node pool context, the prompt cannot accurately assess scheduling risk. Without namespace information, it cannot evaluate whether the change violates namespace-level resource quotas or budget constraints.

Do not use this prompt for evaluating application performance under load, diagnosing memory leaks, or tuning JVM garbage collection parameters. It is not a substitute for vertical pod autoscaling recommendations based on historical metrics. The prompt focuses exclusively on static configuration correctness: will this pod schedule, will it get evicted under memory pressure, will its QoS class change unexpectedly, and what is the cost direction of the change. For runtime behavior analysis, pair this prompt with live profiling data and load test results. For cost optimization recommendations based on actual utilization, use a separate rightsizing prompt that ingests Prometheus or Datadog metrics.

This prompt works best when integrated into a PR review workflow where every resource change triggers an automated assessment. Configure your CI pipeline to extract the resource diff from Helm values files, Kustomize overlays, or raw manifest changes, then pass the structured diff to the prompt along with node pool metadata from your cluster inventory. The prompt's structured output can be posted as a PR comment, used to block merges that introduce Burstable-to-BestEffort regressions, or routed to a human reviewer when the risk score exceeds a threshold. Always require human approval for changes that remove memory limits entirely or that reduce requests below 50% of historical usage without documented justification.

This prompt template is designed to be pasted directly into your AI workflow, whether that's a chat interface, an API call, or an automated CI/CD pipeline. It expects a structured diff of Kubernetes resource configuration changes and produces a standardized risk assessment. Before using it, you must replace every square-bracket placeholder with concrete values. The prompt is self-contained; it includes the role, the task, the required output schema, and evaluation criteria so that the model has everything it needs to produce a consistent, machine-readable result.

codeCopy
You are a senior platform engineer reviewing a Kubernetes pod resource configuration change. Your task is to analyze the provided diff and produce a structured risk assessment.

[INPUT]
### Resource Configuration Diff:
[diff]

### Target Environment:
[ENVIRONMENT]

### Affected Workload Name:
[WORKLOAD_NAME]

### Cluster Node Capacity (optional):
[NODE_CAPACITY]

[OUTPUT_SCHEMA]
You must respond with a single JSON object conforming to this schema:
{
  "change_summary": "string (brief description of the change)",
  "qos_class_change": {
    "previous": "string (Guaranteed | Burstable | BestEffort)",
    "proposed": "string (Guaranteed | Burstable | BestEffort)",
    "risk": "string (none | low | medium | high)"
  },
  "oom_risk": {
    "level": "string (none | low | medium | high | critical)",
    "rationale": "string (explanation based on memory limit vs. request delta and typical usage)"
  },
  "scheduling_risk": {
    "level": "string (none | low | medium | high | critical)",
    "rationale": "string (explanation based on request size vs. available node capacity)"
  },
  "cost_impact": {
    "direction": "string (increase | decrease | neutral)",
    "estimated_magnitude": "string (minimal | moderate | significant)",
    "rationale": "string"
  },
  "findings": [
    {
      "severity": "string (low | medium | high | critical)",
      "category": "string (oom_risk | scheduling | cost | qos | best_practice)",
      "description": "string",
      "recommendation": "string"
    }
  ],
  "overall_verdict": "string (approved | approved_with_comments | needs_review | blocked)"
}

[CONSTRAINTS]
- If the diff sets memory limits without setting memory requests, flag a high-severity best_practice finding.
- If the proposed QoS class is BestEffort for a production workload, the overall_verdict must be "needs_review" or "blocked."
- If CPU limits are removed while requests remain, note the trade-off between throttling risk and cost.
- Do not invent node capacity if [NODE_CAPACITY] is not provided; state that scheduling risk is assessed without full node data.
- Base all rationale on the provided diff, not on assumptions about the application.

[EXAMPLES]
Example Input:
  diff: "- resources: {}\n+ resources:\n+   requests:\n+     memory: \"128Mi\"\n+     cpu: \"100m\"\n+   limits:\n+     memory: \"256Mi\""
  environment: "production"
  workload_name: "payment-processor"

Example Output:
{
  "change_summary": "Added resource requests and limits to a previously unconstrained container.",
  "qos_class_change": {
    "previous": "BestEffort",
    "proposed": "Burstable",
    "risk": "none"
  },
  "oom_risk": {
    "level": "low",
    "rationale": "Memory limit is set to 256Mi, which provides a clear boundary. Risk is low assuming the application operates within this range."
  },
  "scheduling_risk": {
    "level": "low",
    "rationale": "Requests are modest (128Mi memory, 100m CPU). Scheduling risk is low on typical nodes."
  },
  "cost_impact": {
    "direction": "increase",
    "estimated_magnitude": "minimal",
    "rationale": "Moving from BestEffort to Burstable with small requests will have a minimal cost increase."
  },
  "findings": [
    {
      "severity": "medium",
      "category": "best_practice",
      "description": "Container previously had no resource constraints, risking node stability.",
      "recommendation": "Monitor memory usage for a week and adjust requests to P99 usage."
    }
  ],
  "overall_verdict": "approved_with_comments"
}

[RISK_LEVEL]
This is a high-risk workflow. Your output will be used to inform automated merge gates and deployment decisions. If the diff is ambiguous or you lack critical context (like node capacity), state your uncertainty clearly in the rationale fields and escalate the overall_verdict to "needs_review."

To adapt this template, start by replacing the [INPUT] placeholders with data from your GitOps or CI pipeline. The [diff] should be the raw output of kubectl diff or a unified diff from your IaC repository. If you are integrating this into an automated system, parse the JSON output and use the overall_verdict field to gate the merge or deployment. For high-severity findings, route the report to a human reviewer. The [OUTPUT_SCHEMA] is designed to be machine-readable, so you can write a validator that checks for the presence of required fields and rejects malformed responses before they affect a pipeline decision.

This prompt is designed to be called programmatically within a GitOps or CI/CD pipeline, triggered by a pull request that modifies Kubernetes manifests, Helm values files, or Kustomize overlays. The primary integration point is a webhook or pipeline step that extracts the diff of resource configuration changes and passes it as the [CONFIGURATION_DIFF] input. The application harness is responsible for gathering the necessary context—such as the target cluster's current node capacity, the namespace's existing ResourceQuota, and the affected workload's historical resource utilization metrics—and injecting them into the [CLUSTER_CONTEXT] and [WORKLOAD_HISTORY] placeholders. This ensures the model's analysis is grounded in operational reality, not just the manifest syntax.

The harness must enforce a strict validation layer around the model's structured output. After receiving the JSON response, the system should parse it and run a series of checks: verify that the qosClassChange field matches a known set of values (Guaranteed, Burstable, BestEffort), confirm that each finding in the findings array has a non-empty severity and affectedResource, and ensure the overallStabilityAssessment is one of the expected enum values. If the output fails schema validation, the harness should implement a retry loop with a maximum of two attempts, feeding the validation error message back into the prompt's [PREVIOUS_ERROR] placeholder to guide self-correction. After two failed retries, the review should be escalated to a human platform engineer with the raw diff and the failed validation log.

Given the high-risk nature of resource misconfiguration—which can lead to OOM kills, node pressure, or cascading pod evictions—a human approval gate is mandatory for any change flagged with a severity of critical or a riskScore above a configurable threshold (e.g., 8/10). The harness should post the model's structured analysis as a comment on the pull request, explicitly calling out the critical findings and blocking the merge until a designated platform team member approves it. For lower-severity changes, the analysis can serve as an informational review comment. Log every invocation, including the input diff, the model's raw and parsed output, the validation result, and the final human decision, to an audit trail for post-incident review and prompt performance evaluation over time.