CI/CD Without Surprises: 12 Prompts That Make the LLM Write Pipelines, Fix Broken Builds and Explain Terraform Plans in Plain English

A build that fails 40 minutes before a release. A terraform plan with 200 lines of diff where you're scared to touch anything. A docker-compose.yml that has to become Kubernetes manifests "by Friday." These aren't exotic problems — they're Tuesday.

The usual LLM advice ("ask it to write a pipeline") produces a workflow that looks plausible and breaks on the first matrix job, because the model has no idea what your repo looks like. What works is narrow prompts: one task, one input format, one expected output shape, and an explicit instruction to flag assumptions instead of inventing them.

Below are 12 prompts I actually run in DevOps work — pipeline generation, failure triage, container and infra translation, and the boring-but-critical stuff like healthchecks and rollback. Each comes with a real input example and what you should expect back. If you already use LLMs for debugging at the code level, the same discipline from The LLM Detective applies here: give the model evidence, not vibes.

Part 1: Writing pipelines that survive contact with CI

1. GitHub Actions workflow with cache and matrix, generated from a repo description

Problem: you describe a Node/Python service and get a workflow that installs dependencies from scratch on every job, with no matrix and a hardcoded Node version that doesn't match .nvmrc.

Prompt:

You are a senior DevOps engineer. Write a GitHub Actions workflow for this repo.
Inputs: language and version manager files present (list them), test command,
build artifact, deploy target, branch policy.
Requirements:
- use actions/checkout and actions/setup-* with cache: true, keyed on the lockfile
- matrix over the runtimes listed, fail-fast: false
- separate jobs: lint, test, build; build needs [lint, test]
- concurrency group to cancel superseded runs on PRs
- permissions: contents: read at workflow level
Output: the full YAML, then a short list of every value you assumed and why.
If a value is missing from my input, ask — do not invent a version.

Expected result: a workflow where cache: 'npm' (or pip) is wired correctly, the matrix is explicit, and the "assumptions" list lets you catch a wrong runtime before the first run. The assumptions list is the actual deliverable — it's where you find the model's guesses.

2. Port a Jenkinsfile or GitLab CI config to GitHub Actions

Problem: migration projects stall because translating stage/when semantics by hand is error-prone and nobody wants to own the diff.

Prompt:

Translate this Jenkinsfile to GitHub Actions. Preserve behavior exactly:
stages, conditions, environment variables, artifacts, manual approval gates.
Map each Jenkins construct to its GitHub Actions equivalent and list
constructs with NO clean equivalent (e.g. shared libraries, agent labels)
as open questions. Do not silently drop a step.
[Jenkinsfile]

Expected result: a mapping table plus YAML. The open-questions list is what saves you — Jenkins shared libraries and agent { label } don't map 1:1, and a model that pretends they do will hand you a broken pipeline.

3. Add a proper healthcheck and readiness gate

Problem: the container starts, the orchestrator routes traffic, the app isn't ready, users see 502s for 30 seconds after every deploy.

Prompt:

For this service, propose a liveness, readiness and startup probe.
Inputs: framework, port, average cold-start time, dependencies (DB, cache).
Rules: liveness must NOT check dependencies (a DB blip must not restart pods);
readiness should reflect dependency availability; startup probe must cover
cold start with margin. Give initialDelaySeconds, periodSeconds,
failureThreshold for each, and explain each number.

Expected result: three probes with justified timings and the critical distinction spelled out — liveness checks the process, readiness checks the ability to serve. Mixing them is the single most common Kubernetes self-inflicted outage.

Part 2: When the build is red and the clock is ticking

4. Root-cause a failed job from the log

Problem: you paste 300 lines of log and get "try reinstalling dependencies."

Prompt:

Here is a failed CI job log. Do three things:
1. Identify the FIRST error line (not the last) and quote it verbatim.
2. Classify: environment, dependency, test flake, code, or infra.
3. Give the root cause in one sentence, then the minimal fix.
Ignore cascade errors after the first failure — they are noise.
Log:
[log]

Expected result: the model points at the first failure, not the fifty downstream ones. That single instruction — "first error, ignore cascade" — changes the answer quality more than any model upgrade.

5. Flaky test triage

Problem: a test passes locally and fails in CI one run in five. The team reruns until green and learns nothing.

Prompt:

This test is flaky in CI. Given the test code and the last three failure logs,
list the top 3 candidate causes ranked by likelihood (timing, shared state,
network, ordering, clock/timezone). For each, give a one-line experiment to
confirm or eliminate it. Do not suggest 'add sleep' as a fix.

Expected result: ranked hypotheses with falsifiable experiments. The trade-off: you spend time running experiments instead of rerunning the pipeline — but a rerun-until-green culture hides real bugs that surface in production later.

6. Diagnose a Docker build that got slow or huge

Problem: image size crept from 400 MB to 1.2 GB and nobody knows which layer did it.

Prompt:

Here is my Dockerfile and the output of `docker history --no-trunc`.
Identify: the largest layers, layers that invalidate cache on every source change,
and anything running as root. Rewrite the Dockerfile for a multi-stage build
with cache-friendly ordering (deps before source). Show the before/after layer list.

Expected result: a rewritten Dockerfile where COPY package*.json precedes COPY ., plus a named culprit layer. The cache-ordering fix alone typically cuts rebuild time dramatically because dependencies stop reinstalling on every code change.

7. Write a rollback strategy you can actually execute at 2 a.m.

Problem: "we'll just redeploy the previous version" — and then the DB migration already ran.

Prompt:

Propose a rollback plan for this deploy. Inputs: deploy mechanism, DB migration
tool, whether migrations are backward-compatible, traffic routing.
For each failure mode (bad image, bad config, bad migration), give:
- detection signal and time-to-detect
- exact rollback command
- what is NOT reversible and how to mitigate it
Assume the on-call engineer is tired. Number the steps.

Expected result: a runbook that separates reversible from irreversible actions. The honest answer is often "this migration cannot be rolled back — it needs expand/contract," and that's the sentence that prevents a real incident.

Part 3: Terraform, compose and K8s without the guesswork

8. Explain a terraform plan in human language

Problem: 200 lines of diff, and you can't tell whether -/+ on a security group means a brief outage.

Prompt:

Here is `terraform plan` output. Summarize in plain English:
1. Resources created / changed / destroyed / replaced (count each).
2. For every replace (-/+), state whether it causes downtime and why.
3. Flag anything touching stateful resources (DB, storage, DNS) as HIGH RISK.
4. List what a reviewer must manually confirm before apply.
Do not paraphrase attribute-level diffs away — if a value changes, show it.
[plan output]

Expected result: a risk table. The key distinction is replace vs in-place update: a replaced resource is destroyed and recreated, and for anything with attached storage or an IP, that's an outage. A model summarizing "changes to 3 resources" without flagging a replacement is worse than useless.

9. Review a Terraform module for the classic footguns

Prompt:

Review this Terraform code for: hardcoded values that should be variables,
missing lifecycle { prevent_destroy } on stateful resources, resources without
tags, provider version not pinned, and secrets in plaintext.
Output a table: issue | line | severity | fix. Do not rewrite the whole file.

Expected result: a scoped table you can act on. Asking for a table instead of a rewrite keeps the review readable and stops the model from "improving" things you didn't ask about.

10. Convert docker-compose into Kubernetes manifests

Problem: "we're moving to K8s" and someone hand-writes YAML from a compose file, dropping the healthcheck and the volume semantics.

Prompt:

Convert this docker-compose.yml to Kubernetes manifests (Deployment + Service
per service, ConfigMap for env, PVC for named volumes).
Rules: map compose healthcheck to readiness/liveness probes; map depends_on
to an initContainer or document that it has no direct equivalent;
keep resource limits explicit. Output one file per resource, then list
every compose feature with no K8s equivalent.

Expected result: manifests plus a gap list. depends_on is the trap — Kubernetes has no ordering guarantee between pods, so the model should say so rather than fake it.

11. Generate a docker-compose for local dev that mirrors prod

Prompt:

Write a docker-compose.yml for local development of this stack.
Requirements: app + DB + cache, named volumes for DB persistence,
.env file for secrets (not inline), healthcheck on DB, app depends_on DB
with condition: service_healthy. Add a short note on how this differs from prod.

Expected result: a compose file where the app waits for a healthy DB, not just a started one. The "differs from prod" note is what stops someone debugging a bug that only exists locally.

12. Write the ADR / postmortem for the change

Problem: the pipeline works, but six months later nobody remembers why the deploy is blue-green and not rolling.

Prompt:

Write a one-page ADR for this infrastructure decision.
Sections: context, decision, alternatives considered, consequences (good and bad),
what would make us revisit it. Be blunt about the downsides.
Decision: [what you did]

Expected result: a document that names the trade-off, not a sales pitch. This is the cheapest insurance against the next engineer "cleaning up" a deliberate choice.

How to actually run these

Two habits carry most of the value. First, always ask for the assumptions list — it turns a confident hallucination into a visible question. Second, paste real evidence: the actual log, the actual plan, the actual Dockerfile. A model given a real terraform plan is a reviewer; a model given a description of one is a poet.

The same logic that makes these prompts work — evidence in, assumptions surfaced, narrow scope — is what separates a useful review from a rubber stamp, whether the reviewer is a model or a human, as covered in Your Second Reviewer Never Sleeps.

None of this replaces understanding your pipeline. It replaces the two hours you'd spend scrolling YAML and guessing which line broke. Start with prompt 4 on your next red build and prompt 8 on your next terraform plan — those two pay for themselves fastest. Then steal prompt 7's structure for your runbook: the value isn't in the commands, it's in the honest list of what can't be undone.