8 Prompts for CI/CD: GitHub Actions, GitLab CI, and ArgoCD

Introduction

Continuous Integration and Continuous Delivery (CI/CD) pipelines are essential for modern software teams. They automate the journey from code commit to production deployment. Yet many developers spend hours writing and debugging pipeline YAML — even though AI tools can generate it in seconds. This article offers eight ready-to-use prompts for three of the most popular pipeline tools: GitHub Actions, GitLab CI, and ArgoCD. Each prompt is based on official documentation and includes a concrete example you can adapt.

Why These Three Tools?

Before diving into the prompts, let's understand where each tool shines.

GitHub Actions

GitHub Actions integrates natively with GitHub repositories. It uses YAML workflows in the .github/workflows directory. According to the official docs, it supports event triggers like push, pull_request, and even schedule. Its hosted runners come preinstalled with Node.js, Python, Docker, and more.

GitLab CI

GitLab CI uses a single .gitlab-ci.yml file. Its pipeline editor includes a live preview and validation. GitLab also offers CI/CD variables, environments, and a built-in container registry.

ArgoCD

ArgoCD is a declarative GitOps tool for Kubernetes. It continuously syncs your cluster to a desired state defined in a Git repository. The ArgoCD documentation describes Applications, ApplicationSets, and sync policies.

Tool Comparison Table

How to Use These Prompts

Each prompt below is written for an AI assistant. Copy the prompt text, paste it into your favorite AI tool, and review the generated YAML before committing. Always test in a small environment first.

1. Node.js CI Pipeline (GitHub Actions)

Prompt:

Create a GitHub Actions workflow for a Node.js application that runs lint, test, and build on every push to the main branch. Use actions/checkout@v4 and actions/setup-node@v4, cache npm dependencies, and run `npm ci`, `npm test`, `npm run build`.

Explanation: This prompt gives you a complete workflow with caching, which speeds up dependency installation. The output is a YAML file you place in .github/workflows/ci.yml.

Example output:

name: Node.js CI
'on':
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm test
      - run: npm run build

2. Multi-Stage GitLab CI (Python)

Prompt:

Generate a GitLab CI/CD pipeline for a Python package with three stages: `build`, `test`, and `deploy`. Use the `python:3.11` image. In `build`, run `python -m build` to create distributions. In `test`, run `pytest`. In `deploy`, only on the main branch, publish to PyPI using a `PYPI_TOKEN` variable.

Explanation: GitLab CI stages run in order and can fail fast. The only keyword controls when jobs run. The prompt includes a secret variable, which GitLab stores securely.

Example output:

stages: [build, test, deploy]
build:
  stage: build
  image: python:3.11
  script: python -m build
test:
  stage: test
  image: python:3.11
  script: pytest
deploy:
  stage: deploy
  image: python:3.11
  script: |
    pip install twine
    twine upload dist/*
  only: [main]
  variables:
    TWINE_USERNAME: __token__
    TWINE_PASSWORD: $PYPI_TOKEN

3. ArgoCD Application Manifest

Prompt:

Write an ArgoCD Application manifest for a service, named `checkout-service`, that syncs from `https://github.com/acme/checkout-service` to directory `k8s/overlays/production` in namespace `production`. Enable automated pruning and self-healing.

Explanation: This is the core of GitOps: the application describes what should be deployed. ArgoCD will compare the live state to the desired state in Git and apply changes.

Example output:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: checkout-service
  namespace: argocd
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  project: default
  source:
    path: k8s/overlays/production
    repoURL: https://github.com/acme/checkout-service
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

4. Security Scanning with Trivy

Prompt:

Add a security scanning step to a GitHub Actions workflow that builds a Docker image. After the image is built, run aquasecurity/trivy-action to scan for HIGH and CRITICAL vulnerabilities. Fail the build if any are found and upload the SARIF report.

Explanation: Trivy is an open-source vulnerability scanner. The exit-code: '1' setting ensures the pipeline stops on serious issues. This aligns with DevSecOps best practices.

Example output:

- name: Run Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ${{ steps.build.outputs.tags }}
    severity: HIGH,CRITICAL
    exit-code: '1'
    format: sarif
    output: trivy-results.sarif

5. Monorepo Changed-Files Detection

Prompt:

Create a GitHub Actions workflow for a monorepo with `frontend/` and `backend/` directories. The workflow should only run tests for the directory that changed. Use `dorny/paths-filter@v3` to set job outputs and conditionally run test jobs.

Explanation: This approach reduces CI runtime significantly on monorepos because unrelated changes don't trigger a full build.

Example output:

jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      backend: ${{ steps.filter.outputs.backend }}
      frontend: ${{ steps.filter.outputs.frontend }}
    steps:
      - uses: dorny/paths-filter@v3
        id: filter
        with:
          filters: |
            backend: backend/**
            frontend: frontend/**
  backend:
    needs: changes
    if: needs.changes.outputs.backend == 'true'
    steps: ...

6. Automatic Release with Semantic Versioning

Prompt:

Set up a GitLab CI job on the main branch that runs `semantic-release` to automatically determine the next version from commit messages, create a Git tag, add a changelog, and publish the package to npm.

Explanation: Semantic-release enforces conventional commits. It eliminates manual version bumping and reduces human error.

Example output:

release:
  image: node:alpine
  only: [main]
  script:
    - npm install -g semantic-release
    - npx semantic-release

7. ArgoCD ApplicationSet for Multi-Environment

Prompt:

Write an ArgoCD ApplicationSet that generates an Application for each environment in a list: staging and production. For each env, use the same Git repo but different `kustomize` overlays and different namespaces.

Explanation: ApplicationSet is the scalable alternative to creating many Application objects manually. It uses generators like list or git.

Example output:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app
spec:
  generators:
    - list:
        elements:
          - env: staging
          - env: production
  template:
    metadata:
      name: my-app-{{env}}
    spec:
      source:
        repoURL: https://github.com/acme/app
        path: overlays/{{env}}
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{env}}'

8. Slack Notification on Pipeline Failure

Prompt:

Add a Slack notification to a GitHub Actions workflow that sends a message to the #builds channel whenever a job fails. Include the repository name, job name, and a link to the run logs. Use `rtCamp/action-slack-notify@v2` and read the webhook URL from `secrets.SLACK_WEBHOOK`.

Explanation: Instant failure alerts help teams react quickly and keep the CI/CD feedback loop short.

Example output:

- name: Slack notification
  if: failure()
  uses: rtCamp/action-slack-notify@v2
  env:
    SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
    SLACK_TITLE: CI Failed
    SLACK_MESSAGE: The build failed in ${{ github.repository }}

Conclusion

These eight prompts cover everything from simple CI jobs to GitOps deployment and multi-environment management. Copy a prompt, tweak it for your project, and run it through an AI assistant to get a base YAML file. Then validate it with your tool's linter and commit. With AI-assisted pipeline authoring, you can spend less time on YAML syntax and more time on building features.

For more information, check the official documentation for GitHub Actions, GitLab CI, and ArgoCD.