Good CI/CD prompts give the model the commands you already run locally, the CI system you use, what triggers a run and where you deploy, then ask for specific safeguards: least-privilege permissions, caching, timeouts and approvals before production. Below are 13 CI/CD prompts for ChatGPT, Claude, Claude Code and Codex for writing pipelines in GitHub Actions and GitLab CI, making them faster, fixing failed jobs, deploying safely and securing workflows.
How to use these prompts
Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{ci:GitHub Actions}} means GitHub Actions unless you change it.
Three habits make CI answers much better:
- Start from what works locally. List the exact commands for install, lint, test and build. The pipeline should run the same ones.
- Paste real output. For slow or failing pipelines, the job log and step timings beat any description.
- Test on a branch. Push the workflow to a branch or open a draft pull request and watch the run before merging it.
In an agent, let it read package.json, the Makefile, the Dockerfile and existing workflow files, so the pipeline matches the project.
Infrastructure pipelines have their own collection: the Terraform prompts include a CI workflow for plan and apply, and the Docker prompts cover faster image builds.
How do you write a CI pipeline with AI?
1. Write a GitHub Actions CI workflow
The starting prompt for most projects. GitHub's workflow syntax reference covers permissions, concurrency and the other keys this prompt asks for.
Write a GitHub Actions workflow that runs CI for a {{language:Node.js}}
project on every pull request and on pushes to {{branch:main}}.
Commands:
- Install: {{install:npm ci}}
- Lint: {{lint:npm run lint}}
- Test: {{test:npm test}}
- Build: {{build:npm run build}}
Requirements:
- Top-level permissions set to contents: read, raising them only per job
if a job needs more.
- Dependency caching through the setup action's built-in cache option.
- A concurrency group per branch that cancels in-progress runs on new
pushes to pull requests, but never cancels runs on main.
- A timeout-minutes value on every job.
- Pin third-party actions to a full commit SHA with the version in a
comment.
Explain each section in one line.
2. Write a GitLab CI pipeline
The same job for .gitlab-ci.yml. GitLab's CI/CD YAML reference documents rules, needs, cache, interruptible and workflow:rules.
Write a .gitlab-ci.yml for a {{language:Python}} project.
Stages: {{stages:lint, test, build, deploy}}
Commands: {{commands}}
Deploy target: {{target:staging on merge to main, production by manual approval}}
Requirements:
- workflow:rules so pipelines run for merge requests and the default
branch, without duplicate pipelines for the same push.
- needs so independent jobs start without waiting for the whole stage.
- A cache keyed on the lockfile, and artifacts with an expire_in value.
- interruptible on jobs that are safe to cancel when a newer pipeline
starts.
- An environment on each deploy job.
Explain each keyword the first time you use it.
3. Translate a pipeline between CI systems
For migrations between GitHub Actions, GitLab CI and other systems. Asking for a list of non-equivalent features is the important part.
Translate this {{from:GitLab CI}} pipeline into {{to:GitHub Actions}}.
{{pipeline}}
Keep the same jobs, order, triggers, caching, artifacts, secrets and
deploy rules. Use idiomatic features of the target system instead of a
line-by-line copy. Then list everything that doesn't map directly
(for example, manual jobs, resource groups or protected variables) and
how you handled each one, so I can check them by hand.
4. Add a test matrix
When you support several runtime versions or operating systems, a matrix runs every combination. GitHub's matrix guide covers include, exclude, fail-fast and max-parallel.
Add a test matrix to this workflow so tests run on
{{versions:Node.js 22 and 24}} and {{os:ubuntu-latest and windows-latest}}.
{{workflow}}
Exclude combinations we don't need: {{exclude:none}}. Decide whether one
failure should cancel the other jobs and explain the choice. Keep lint and
build out of the matrix so they run once. Show the full updated workflow.
How do you make CI faster?
5. Speed up a slow pipeline
Most slow pipelines have two or three causes that show up clearly in the timings.
Our CI pipeline takes {{duration:18 minutes}}. Here is the workflow and the
time each job and step took on a typical run.
Workflow:
{{workflow}}
Timings:
{{timings}}
Rank the changes that would save the most time: caching, running jobs in
parallel, skipping work when only unrelated files change, splitting slow
test suites, using smaller or prebuilt images, and cancelling superseded
runs. Estimate the saving for each and show the changed YAML for the top
three.
6. Fix a cache that never hits
A cache that misses every run costs time to save and gives nothing back. In GitHub Actions, actions/cache checks restore-keys as prefix matches when the exact key misses, and entries not accessed in over 7 days are removed.
Our dependency cache in {{ci:GitHub Actions}} misses on almost every run.
Cache configuration:
{{cache_config}}
Log lines from the cache step on two consecutive runs:
{{logs}}
Explain why it misses: a key that changes every run, paths that don't
match where the package manager writes, caches saved on one branch and
not visible from another, or eviction. Give a corrected configuration with
a key based on the lockfile and sensible restore keys.
7. Split a slow test suite into shards
When tests alone take most of the pipeline, running them in parallel shards is often the biggest win.
Our test suite takes {{duration:12 minutes}} in CI with {{runner:Jest}}.
Split it across {{shards:4}} parallel jobs in {{ci:GitHub Actions}}.
Use the runner's built-in sharding if it has one. Balance shards by test
duration, not file count, if timing data is available. Merge test results
and coverage from all shards into one report, and make the pipeline fail
if any shard fails. Show the YAML and explain how to rebalance later.
How do you debug a failing pipeline?
8. Read a failed job log
CI logs are long and the real error is rarely the last line.
This CI job failed. Here is the full log.
{{log}}
The workflow file:
{{workflow}}
Find the first real error, not the cascade after it. Explain the cause in
plain language, tell me whether it is a code problem, a test problem, a
pipeline configuration problem or an infrastructure blip, and give the
fix. If you need more information, tell me exactly which command to run
or which log line to look for.
9. Passes locally, fails in CI
Almost always an environment difference. Listing the differences finds it faster than guessing.
These tests pass on my machine but fail in {{ci:GitHub Actions}}.
Failure output:
{{failure}}
My local setup: {{local:macOS, Node.js 22, Docker Desktop}}
CI setup (from the workflow):
{{workflow}}
List the environment differences that could explain it: OS and file
system case sensitivity, timezone and locale, runtime versions, missing
environment variables or services, parallelism, network access, and
leftover local state. Rank them for this failure and tell me how to
reproduce the CI environment locally to confirm.
How do you deploy safely from CI?
10. Write a deploy workflow with approvals
Production deploys should wait for a person. GitHub environments support required reviewers (up to 6 people or teams), wait timers and limits on which branches can deploy. On GitHub Free, Pro and Team plans, required reviewers and wait timers are only available for public repositories.
Write a deployment workflow for {{app:our web app}} to {{target:AWS}}.
Flow: build once, deploy the same artifact to staging automatically, run
smoke tests, then deploy to production only after approval.
Requirements:
- Use GitHub environments named staging and production; production
requires a reviewer and only accepts deployments from {{branch:main}}.
- Never rebuild between staging and production.
- Only one deployment per environment at a time.
- Print the deployed version and URL in the job summary.
List the settings I need to configure in the repository, not only the YAML.
11. Replace long-lived cloud keys with OIDC
Static cloud keys in CI secrets are a common leak. GitHub's OIDC documentation says: "You won't need to duplicate your cloud credentials as long-lived GitHub secrets."
Our workflow deploys to {{cloud:AWS}} using access keys stored as GitHub
secrets. Switch it to OpenID Connect.
Current workflow:
{{workflow}}
Give me: the cloud-side setup (identity provider and a role or service
account), a trust policy restricted to {{repo:our-org/our-repo}} and the
{{branch:main}} branch or production environment, the workflow changes
including the id-token: write permission on the deploy job only, and how
to test it before deleting the old keys.
12. Add smoke tests and an automatic rollback
A deploy that succeeds but serves errors is still a failed deploy.
After each deploy of {{app:our API}} to {{target:Kubernetes}}, add a
smoke test step and an automatic rollback.
Health endpoint: {{health:/healthz}}
Critical checks: {{checks:login works, the homepage loads, one read API call returns 200}}
Write the smoke tests with retries and a total time limit, then the
rollback step that runs only if they fail and returns to the previous
version. Make the job fail loudly and notify {{channel:the team chat}}
either way. Explain what the rollback does not undo, such as database
migrations.
How do you secure a CI/CD pipeline?
13. Security review of a workflow file
Workflows can read secrets and push code, so they deserve a review like any production code. GitHub's secure use reference recommends pinning actions to a commit SHA, granting GITHUB_TOKEN the minimum permissions, passing untrusted input through an intermediate environment variable, and avoiding pull_request_target when it isn't necessary.
Review this {{ci:GitHub Actions}} workflow for security problems.
{{workflow}}
Check:
1. Permissions: is GITHUB_TOKEN limited to what each job needs?
2. Third-party actions: pinned to a full commit SHA?
3. Script injection: does any untrusted value (pull request title or
body, branch name, issue comment) reach a run step directly, instead
of through an environment variable?
4. Triggers: does pull_request_target or workflow_run check out and run
code from a fork?
5. Secrets: could any secret be printed, passed to an untrusted action
or exposed to forked pull requests?
For each finding, give the risk, the line and the fixed YAML.
What should you check before merging a pipeline change?
| Check | How |
|---|---|
| It runs | Push to a branch and watch the full run |
| It fails when it should | Break a test on purpose; the pipeline must go red |
| Permissions are minimal | Read the permissions block for every job |
| Actions are pinned | Every third-party uses line points at a full commit SHA |
| Secrets stay secret | Search logs for secret values; forked pull requests get none |
| Deploys need approval | Production environment has reviewers and branch rules |
Turn your favorite one into a skill
If you set up pipelines for many repositories, the CI workflow and security review prompts make good skills: Claude Code or Codex can then apply your house rules to every new workflow. Paste one into the free SKILL.md generator, or start from the GitHub Actions templates skill guide. To run an agent inside your pipeline, see Claude Code GitHub Actions and the Codex GitHub Action. The API testing prompts and performance optimization prompts cover the tests worth running in CI.
Kipt keeps prompts like these as Markdown in a private GitHub repo you own. Blanks like {{ci:GitHub Actions}} stay fillable, Cmd+K finds any prompt, and skills you save there install into Claude Code or Codex with one command.