CI/CD Pipeline Variable Audit Prompt

Release engineers and platform teams often manage variables scattered across multiple CI/CD systems: GitHub Actions, GitLab CI, Jenkins, and deployment scripts. Manual audits miss stale variables, inconsistent naming, and secrets that should be masked but are not. This prompt takes raw pipeline configuration files from one or more CI/CD systems and produces a unified variable matrix showing where each variable is defined, where it is consumed, its sensitivity classification, and whether drift exists between environments. Use this prompt when you need a single source of truth for pipeline variables before a security review, compliance audit, or platform migration.

The ideal user is a release engineer, DevOps lead, or security reviewer who has access to raw pipeline configuration files (e.g., .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile) and environment-specific variable overrides. The prompt requires you to supply these files as structured input, along with any known environment groupings (dev, staging, production) and a sensitivity classification policy. The output is a structured matrix—typically a Markdown table or JSON array—that maps each variable to its definition points, consumption points, environments, and risk classification. This matrix becomes the input for drift detection, secret rotation planning, and audit evidence collection.

Do not use this prompt when you need real-time secret scanning or runtime injection verification; those require tool-based approaches (e.g., secret scanners, runtime config inspectors) rather than prompt-based static analysis. This prompt also cannot validate that a variable's value is correct at runtime—it only analyzes configuration files as provided. For high-stakes audits, always pair the prompt output with human review of the sensitivity classifications and drift findings before taking action on production pipelines.

This prompt template is designed to be dropped directly into your AI orchestration layer or evaluation harness. It instructs the model to scan pipeline definitions from multiple CI/CD systems, extract every variable reference, and produce a structured matrix showing where each variable is defined, consumed, and whether it is classified as a secret. The output is a machine-readable audit artifact that your release engineering team can use to detect configuration drift, identify orphaned variables, and enforce consistent secret handling across environments.

textCopy
You are a CI/CD pipeline auditor. Your task is to analyze pipeline definitions from the provided sources and produce a unified variable audit matrix.

## INPUT
Pipeline definitions from the following sources:
[PIPELINE_DEFINITIONS]

Environment labels for each source:
[ENVIRONMENT_LABELS]

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "audit_matrix": [
    {
      "variable_name": "string",
      "defined_in": ["source_file_path"],
      "consumed_in": ["source_file_path"],
      "environments": ["env_label"],
      "is_secret": boolean,
      "has_default": boolean,
      "default_value_hint": "string or null",
      "drift_detected": boolean,
      "drift_details": "string or null",
      "risk_level": "low | medium | high | critical"
    }
  ],
  "summary": {
    "total_variables": number,
    "secrets_count": number,
    "drifted_variables": number,
    "orphaned_variables": number,
    "high_risk_count": number
  }
}

## CONSTRAINTS
- Classify a variable as a secret if it references a secret store, uses a masked value pattern, or is named with secret/token/key/password/credential conventions.
- Flag drift when the same variable name has different values, different secret classifications, or different default behaviors across environments.
- Mark a variable as orphaned if it is defined but never consumed in any pipeline step.
- Assign risk_level "critical" to any secret variable with detected drift or orphaned secrets with no clear owner.
- If a variable's purpose is unclear from context, set default_value_hint to null and note it in drift_details.
- Do not invent variable values. Only report what is present in the provided definitions.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## TOOLS
[AVAILABLE_TOOLS]

## RISK_LEVEL
[HUMAN_REVIEW_REQUIRED]

To adapt this template for your environment, replace the square-bracket placeholders with your actual pipeline sources and configuration. [PIPELINE_DEFINITIONS] should contain the full text of your GitHub Actions workflow files, GitLab CI YAML, Jenkinsfiles, or any other pipeline-as-code artifacts. [ENVIRONMENT_LABELS] maps each source to its environment name (e.g., dev, staging, production-us-east, dr). If you have few-shot examples of correctly audited variables from a previous manual review, include them in [FEW_SHOT_EXAMPLES] to improve classification accuracy. The [AVAILABLE_TOOLS] placeholder should list any functions the model can call, such as a secret store lookup or a config schema validator. Set [HUMAN_REVIEW_REQUIRED] to true when auditing production pipelines or when the audit will trigger automated remediation; set to false for pre-production dry runs where a human will review the output before any action is taken.

Before deploying this prompt into a production audit workflow, validate the output against a known-good pipeline with a small set of variables. Check that the model correctly distinguishes secrets from non-secrets, identifies drift where you have intentionally introduced it, and does not hallucinate variable names or values. Run the prompt through your evaluation harness with at least three pipeline configurations that include edge cases: a variable defined in one environment but missing in another, a secret that is accidentally logged in a non-secret context, and a deprecated variable that still appears in a pipeline but is no longer consumed. If the model misses any of these, add a corresponding few-shot example and re-test before expanding to your full pipeline inventory.

This prompt is designed to be called programmatically, not as a one-off chat interaction. The primary integration point is a script or CI job that collects pipeline definitions (.github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile), serializes them into the [PIPELINE_DEFINITIONS] placeholder, and sends the assembled prompt to a model API. The output is a structured variable matrix, which means your harness must parse and validate the model's response before it becomes actionable. Treat the model as an unreliable parser that needs a strict post-processing contract.

Integration steps: (1) Build a collector that walks the repository and reads all pipeline definition files into a single context string, prefixing each with its file path. (2) Inject the collected definitions into the prompt template's [PIPELINE_DEFINITIONS] placeholder. (3) Call the model with response_format set to json_object (or equivalent structured output mode) and a low temperature (0.0–0.2) to maximize determinism. (4) Parse the response and validate each entry against a JSON Schema that requires variable_name, defined_in, consumed_in, is_secret, and type fields. Reject any entry missing required fields. (5) Run a cross-reference check: every variable listed as consumed_in must appear in the defined_in list of at least one file; flag orphans for human review. (6) Store the validated matrix as a versioned artifact (e.g., variable-audit-{commit-hash}.json) so you can diff it across commits and detect drift.

Failure modes to handle: The model may hallucinate variable names that don't exist in the source, misclassify build arguments as secrets, or omit variables defined inside reusable workflow calls. Mitigate hallucination by implementing a post-processing step that greps the original pipeline files for each reported variable name and removes entries with zero matches. For secret detection, prefer a deterministic regex scan (secrets.*, ${{ secrets.) as a secondary check rather than trusting the model's classification alone. If the output fails schema validation, implement a single retry with the validation errors injected back into the prompt as [PREVIOUS_ERRORS]. If the retry also fails, log the raw response and alert a human instead of silently proceeding with incomplete data. Never use this prompt's output to automatically rotate or delete variables—only to surface audit findings for human review.