Generating a Dockerfile that ignores .env but still works in CI is a classic failure. Here’s a set of copy-paste prompts that force LLMs to produce deployment-ready CI/CD code, not just plausible-looking YAML.
Prompt Templates for CI/CD Pipelines solve one specific problem: LLMs hallucinate pipeline syntax, invent non-existent GitHub Actions steps, and ignore your actual build system. These three templates — scoped, context-rich, and failure-aware — work with Claude 3.5, GPT-4, Gemini 1.5, and DeepSeek-V2. I’ve tested all of them on real repos.
Why Generic Prompts Fail Here
"Write a CI/CD pipeline for my Node.js app" produces garbage. The LLM guesses your package manager, assumes you use npm, and emits a generic actions/checkout@v3 flow that breaks the moment you have a monorepo or a custom build step.
The failure mode is missing constraints. CI/CD is all about constraints: which OS, which Node version, which secrets, which cache keys, which failure policies. Generic prompts omit all of them, so the LLM fills the gaps with its training-data average — which matches almost nobody.
These templates fix that by forcing you to declare the constraints upfront. The LLM then has enough structure to produce something that actually runs.
Template 1: The Context-Injected Pipeline
This template works for any language. It forces the LLM to read your actual config before writing a single line of YAML.
You are a CI/CD engineer. I have a repository at {REPO_PATH} with the following build setup:
- Primary language: {LANGUAGE}
- Package manager / build tool: {BUILD_TOOL}
- Test command: {TEST_COMMAND}
- Deploy target: {DEPLOY_TARGET} (e.g., AWS ECS, Vercel, Docker Hub)
- CI platform: {CI_PLATFORM} (GitHub Actions, GitLab CI, Jenkins)
Write a complete pipeline file for {CI_PLATFORM} that:
1. Checks out the code
2. Installs dependencies using {BUILD_TOOL} with caching enabled
3. Runs {TEST_COMMAND} on every push and pull request
4. Builds a production artifact
5. Deploys to {DEPLOY_TARGET} only on push to main
6. Includes a rollback trigger if the deploy step fails
Output the full file in a code block. Do not use placeholder comments — write real commands.
Placeholders:
{REPO_PATH}: local path or URL — the LLM may read it if you're using a coding agent{BUILD_TOOL}: npm, yarn, pip, gradle — this changes the cache keys and install commands{CI_PLATFORM}: this changes the entire syntax (YAML vs. Groovy vs. Jenkinsfile)
Template 2: The Failure-First Pipeline
This one targets the hardest part of CI/CD: what happens when something breaks. Most LLMs write happy-path pipelines that fail silently.
You are writing a CI/CD pipeline for {CI_PLATFORM}. The pipeline must handle these failure scenarios explicitly:
1. If the dependency install step fails, retry once with a clean cache, then fail the build.
2. If tests fail, upload the test report as an artifact and mark the job as failed — do not deploy.
3. If the deploy step fails, automatically roll back to the previous successful deployment.
4. If the pipeline is re-run, it must use cached dependencies from the previous run where possible.
Here is my current pipeline file: {PASTE_EXISTING_PIPELINE}
Rewrite this pipeline to include all four failure-handling behaviors. Preserve my existing steps where they work. Add comments explaining each failure-handling block. Output the complete file.
This works well because it gives the LLM a concrete artifact to modify, plus explicit failure modes. The "preserve existing steps" instruction stops it from rewriting everything and breaking your working setup.
Template 3: The Multi-Environment Edge Case
This is for monorepos or microservices where a single pipeline doesn't cut it.
I have a monorepo with {NUMBER_OF_SERVICES} services in these directories: {SERVICE_PATHS}. Each service has its own package.json, but they share a root lockfile.
Write a CI/CD pipeline on {CI_PLATFORM} that:
1. Detects which services changed in the current commit (use git diff against the previous commit)
2. Only builds and tests the changed services — do not waste CI minutes on unchanged ones
3. Deploys each changed service to its own environment: {ENV_MAPPING} (e.g., service-a -> staging, service-b -> production)
4. Runs integration tests that span multiple services only if more than one service changed
5. Uses a matrix strategy where possible to parallelize across services
The pipeline must fail if the git diff detection fails. Output the complete pipeline file.
This is the hardest template because it requires the LLM to reason about git state, conditional execution, and matrix strategies. Most models handle it decently with Claude or GPT-4, but Gemini might produce a simpler version — still usable, just less optimal.
How to Adapt These for Your Own Codebase
Don't copy-paste these verbatim. The value is in the structure, not the text.
First, always paste your actual pipeline file when asking for modifications. The LLM works better with something to edit than a blank slate.
Second, add your exact secret names. If your deploy step needs AWS_ACCESS_KEY_ID, write it in the prompt. The LLM will reference it correctly instead of inventing a generic DEPLOY_TOKEN.
Third, specify your caching strategy. Every CI platform has different cache syntax. If you use actions/cache with a custom key, mention it. Otherwise the LLM will use its default, which may not match your setup.
Finally, test the output in a dry-run mode if your CI platform supports it. GitHub Actions has act, GitLab has --dry-run. Never trust the LLM output blindly.
Do These Prompts Work With Any LLM?
No. Claude 3.5 and GPT-4 handle all three templates well — they respect the constraint structure and produce syntactically valid output. Gemini 1.5 works for Template 1 and 2 but struggles with the multi-service conditional logic in Template 3. DeepSeek-V2 produces reasonable output but sometimes misses the rollback logic in Template 2.
The failure rate also depends on the CI platform. GitHub Actions is over-represented in training data, so all models do better with it. Jenkins Groovy pipelines have less training data — expect more hallucinated methods. If you're on a less common platform, add one line to the prompt: "Only use syntax that exists in the official documentation for this platform."
The one adjustment that improves these prompts the most: add your actual error logs from the last failed pipeline run. Paste the stack trace, the failing step output, and the CI platform's error message. The LLM will then generate a fix that targets your real problem instead of a generic one.