CI/CD Pipeline Configuration Change Review Prompt

This prompt is built for DevOps and platform engineers who need a structured, automated first pass on pipeline configuration diffs before they merge. The job-to-be-done is clear: catch injection surfaces, credential leaks, and deployment gate bypasses that manual review often misses. You should use this prompt when a pull request modifies files like .gitlab-ci.yml, .github/workflows/*.yml, Jenkinsfile, or any script that executes during build, test, or deploy stages. The required context is a unified diff of the changed pipeline configuration, and the expected output is a machine-readable JSON report that maps each finding to a specific stage, line reference, severity, and remediation step. This prompt does not replace human approval for production pipeline changes, but it ensures that reviewers never miss the highest-risk patterns hidden in routine configuration updates.

Do not use this prompt for reviewing application source code, infrastructure-as-code templates like Terraform, or Kubernetes manifests. Those require different risk models and output schemas. This prompt is also not suitable for runtime log analysis or post-deployment incident forensics—it is a pre-merge review tool. For high-security environments, pair this prompt with a human-in-the-loop approval step that blocks the merge until all high-severity findings are resolved or waived. The prompt's value is in its consistency: it applies the same security and integrity checks to every pipeline change, regardless of the reviewer's experience level or time pressure. Wire it into your PR workflow as a required status check, and configure your CI system to run it automatically whenever pipeline configuration files are touched.

Before you integrate this prompt, ensure your pipeline configuration is stored in a version-controlled repository and that your CI system can produce a clean unified diff. The prompt expects the full diff context, not just the changed lines, so it can reason about surrounding stages and dependencies. If your pipeline spans multiple files, concatenate the diffs into a single input block. Start with a dry-run mode that posts findings as PR comments without blocking the merge, then graduate to a blocking check once your team tunes the severity thresholds and false positive handling. The next section provides the copy-ready prompt template you can adapt to your specific pipeline tooling and organizational policies.

The following prompt template is designed to be pasted directly into your AI harness. It expects a unified diff of pipeline configuration changes and produces a structured risk report. All placeholders are enclosed in square brackets. Replace them with your specific pipeline context, organizational policies, and output format requirements before execution. The template is self-contained and can be used independently of the surrounding playbook.

textCopy
You are a senior DevSecOps engineer reviewing a CI/CD pipeline configuration change. Your task is to analyze the provided diff for security risks, reliability regressions, and deployment gate integrity issues.

## INPUT
[PIPELINE_CONFIG_DIFF]

## CONTEXT
- Pipeline Name: [PIPELINE_NAME]
- Service/Repository: [SERVICE_NAME]
- Deployment Environment: [TARGET_ENVIRONMENT]
- Organizational Policies: [POLICY_DOCUMENT_OR_RULES]

## INSTRUCTIONS
1. Parse the diff to identify every modified stage, step, job, trigger, variable, and approval gate.
2. For each change, assess the following risk categories:
   - **Injection Risk**: Unsanitized user input, untrusted parameters, or dynamic script construction in `run` blocks.
   - **Credential Exposure**: Secrets in plaintext, environment blocks, or build arguments; missing secret references.
   - **Artifact Integrity**: Changes to artifact upload/download paths, missing checksum verification, or tamperable storage.
   - **Deployment Gate Bypass**: Removed or weakened approval steps, environment protection rule changes, or auto-approval triggers.
   - **Pipeline Drift**: Inconsistencies between deployment environments or stages that introduce configuration skew.
3. For every finding, provide:
   - **Stage/Job Name**: The specific pipeline component.
   - **Line Reference**: The line number(s) in the diff where the issue originates.
   - **Severity**: CRITICAL, HIGH, MEDIUM, or LOW.
   - **Finding**: A concise description of the risk.
   - **Remediation**: A specific, actionable fix.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "summary": "A one-paragraph executive summary of the change and overall risk posture.",
  "findings": [
    {
      "stage": "string",
      "line_ref": "string or [start, end]",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "category": "INJECTION|CREDENTIAL_EXPOSURE|ARTIFACT_INTEGRITY|GATE_BYPASS|PIPELINE_DRIFT",
      "finding": "string",
      "remediation": "string"
    }
  ],
  "approval_recommendation": "APPROVE|APPROVE_WITH_COMMENTS|BLOCK",
  "human_review_required": true or false
}

## CONSTRAINTS
- Do not flag placeholder values, test fixtures, or example variables as credential exposure unless they use realistic patterns.
- If a change is purely cosmetic (comments, formatting, stage renaming with no logic change), do not generate a finding.
- If the diff is empty or unparseable, return a single finding with severity LOW and category PIPELINE_DRIFT explaining the issue.
- Base all findings strictly on the diff and provided context. Do not speculate about code not present in the diff.

To adapt this template, replace the square-bracket placeholders with your actual data. [PIPELINE_CONFIG_DIFF] should receive the raw unified diff from your version control system. [POLICY_DOCUMENT_OR_RULES] can be a summary of your organization's security and deployment policies, such as 'All production deployments require a manual approval gate' or 'Secrets must be referenced from HashiCorp Vault'. If you need a different output format, modify the OUTPUT_SCHEMA block to match your downstream consumer, such as a Slack notification, Jira ticket, or GitHub Check Run annotation. For high-risk pipelines controlling production infrastructure, always set human_review_required to true in your harness logic when the model returns a BLOCK recommendation or any CRITICAL severity finding.

Before integrating this prompt into an automated CI check, run it against a curated set of historical pipeline diffs with known findings. Compare the model's output to your expected results to calibrate severity thresholds and reduce false positives on benign changes like stage reordering or comment additions. Pay particular attention to false negatives in the GATE_BYPASS category, as these are the most likely to cause production incidents if missed.

This prompt is designed to run inside a CI/CD pipeline webhook or a chat-ops command, not as a one-off copy-paste. The application harness should receive a pipeline configuration diff (YAML, JSON, or HCL), inject it into the [PIPELINE_CONFIG_DIFF] placeholder, and call the model. The output is a structured JSON object containing an array of findings, each with a stage_reference, line_reference, severity, and description. The harness must validate this JSON before surfacing it to the user or blocking a merge. A common integration point is a GitHub Actions workflow that triggers on pull requests touching .github/workflows/, Jenkinsfile, .gitlab-ci.yml, or bitbucket-pipelines.yml.

Validation and retry logic. After receiving the model response, the harness must validate that the output is valid JSON conforming to the expected schema. If validation fails, retry once with the same prompt and append a repair instruction: Your previous output was not valid JSON matching the required schema. Return ONLY the corrected JSON object. If the second attempt also fails, log the raw response and surface a REVIEW_REQUIRED status to the developer. Do not silently accept malformed output. For high-risk pipelines (production deployment, credential rotation, or security scanning), always require human approval before merging, regardless of the model's findings.

Model choice and latency budget. This task benefits from a model with strong structured output capabilities and instruction following. A model like Claude 3.5 Sonnet or GPT-4o works well. Set a timeout of 30 seconds and a max_tokens of 4096 to accommodate detailed findings. If the pipeline diff is large (over 2000 lines), pre-process it by extracting only changed sections using git diff or a YAML-aware differ before sending it to the model. This reduces token cost and improves focus. For teams running many reviews per day, consider caching the system prompt prefix and batching non-urgent reviews during off-peak hours.

Logging and observability. Log the full prompt, model response, validation result, and reviewer decision for every invocation. Attach the pipeline name, commit SHA, and PR number as metadata. This creates an audit trail for compliance reviews and helps debug false positives. If a finding is dismissed by a human reviewer, capture the dismissal reason and feed it back as a negative example in future prompt iterations. Avoid logging the raw pipeline config if it contains secrets; use a pre-processing step to redact environment variable values and credential blocks before they reach the model or the log store.