ShortIQ

ShortIQ

AI

50 AI Prompts for GitHub Actions and CI/CD Pipelines

50 AI prompts for building GitHub Actions workflows. Covers pull request checks, automated testing, Docker builds, deployment to AWS and Vercel, release automation, matrix testing, secrets management, and workflow optimisation.

June 16, 2026•ShortIQ Editorial Team

Getting the Most from These GitHub Actions Prompts

GitHub Actions is the most widely adopted CI/CD platform for open source and private repositories. These 50 prompts cover the full range of GitHub Actions use cases: automated checks on pull requests, multi-platform testing, Docker image builds, deployments to every major cloud provider, release automation, and workflow performance optimisation.

When using these prompts, always specify your project stack (Node.js version, language, framework), your deployment target, and any specific secrets or environments you are using. GitHub Actions YAML is sensitive to indentation — specify that you want the output as a complete workflow file including the name, on, and jobs keys so the indentation context is always clear.

Pull Request Checks and Testing (Prompts 1-18)

Prompt 1: Write a GitHub Actions CI workflow for a Node.js TypeScript project. Trigger on pull requests to main and on push to main. Set up Node.js 20 with npm cache, install dependencies, run TypeScript type checking with npx tsc --noEmit, run ESLint, run Jest tests with coverage, and upload the coverage report to Codecov. Fail the workflow if any step fails.

Prompt 2: Create a GitHub Actions matrix testing workflow that runs tests across multiple Node.js versions (18, 20, 22) and operating systems (ubuntu-latest and windows-latest). Show the matrix strategy, how to reference matrix values in steps, and how to allow specific matrix combinations to fail without failing the whole workflow using continue-on-error. Prompt 3: Write a GitHub Actions workflow that runs on pull requests and posts the test results as a comment on the PR using the GitHub API. Include the number of passing and failing tests, code coverage percentage compared to the base branch, and a link to the full workflow run log.

  • Prompt 4: Create a GitHub Actions workflow for a Python project. Set up Python 3.12, install dependencies from requirements.txt, run black for formatting, run flake8 for linting, run mypy for type checking, and run pytest with coverage. Cache the pip cache between runs.
  • Prompt 5: Write a GitHub Actions workflow for a Go project. Set up Go 1.22, cache the Go module cache, run go vet, run staticcheck for additional linting, run go test ./... with the race detector enabled, and build the binary to verify compilation succeeds.
  • Prompt 6: Create a GitHub Actions workflow that runs Playwright end-to-end tests against a Next.js application. Start the Next.js dev server in the background, wait for it to be healthy using wait-on, run Playwright tests, and upload test screenshots and videos as artifacts when tests fail.
  • Prompt 7: Write a GitHub Actions workflow that checks for dependency vulnerabilities. Run npm audit for high and critical severity issues and fail the workflow if any are found. Also run a license check to ensure no GPL-licensed packages are added to a commercial project.
  • Prompt 8: Create a GitHub Actions workflow that enforces branch naming conventions. Trigger on pull request opened and fail with a descriptive error message if the branch name does not match feature/, bugfix/, hotfix/, or release/ prefixes. Post the error as a PR check status.
  • Prompt 9: Write a GitHub Actions workflow that runs database migration tests. Start a PostgreSQL service container, run the migration up command, verify the schema is correct by running a schema snapshot test, run the migration down command, and verify the database is back to the previous state.
  • Prompt 10: Create a GitHub Actions concurrency configuration that cancels in-progress runs for the same branch when a new push arrives, but never cancels runs on main. Show the concurrency group definition and cancel-in-progress setting.
  • Prompt 11: Write a GitHub Actions workflow step that only runs when specific files change using the paths filter on the on.push and on.pull_request triggers. Separate a monorepo so the backend workflow only triggers when files under api/ change and the frontend workflow only triggers when files under client/ change.
  • Prompt 12: Create a GitHub Actions reusable workflow for running tests. Define it in .github/workflows/test.yml with inputs for node-version and test-command. Show how a caller workflow in .github/workflows/ci.yml references the reusable workflow using the uses key and passes inputs.
  • Prompt 13: Write a GitHub Actions workflow that generates and publishes an npm package. Trigger on push to a release/ branch, run tests, bump the version using npm version, publish to the npm registry using a stored NPM_TOKEN secret, and create a git tag for the release.
  • Prompt 14: Create a GitHub Actions step that caches node_modules between workflow runs. Cache on the hash of package-lock.json, restore on cache hit, run npm ci only on cache miss, and show the cache hit/miss output.
  • Prompt 15: Write a GitHub Actions workflow that enforces a PR title convention following Conventional Commits (feat:, fix:, docs:, chore:, etc.). Trigger on pull_request_target with types: [opened, edited], validate the title against a regex, and fail the check with a clear message listing allowed prefixes.
  • Prompt 16: Create a GitHub Actions workflow that runs a security scan using Trivy. Scan the codebase for secrets and vulnerabilities in dependencies, fail if any CRITICAL or HIGH vulnerabilities are found, and upload the results as a SARIF file to GitHub Security so they appear in the Security tab.
  • Prompt 17: Write a GitHub Actions workflow that auto-assigns reviewers to pull requests based on the files changed. If files under api/ are changed, assign the backend team. If files under client/ are changed, assign the frontend team. Use a CODEOWNERS file and the auto-assign action.
  • Prompt 18: Create a GitHub Actions workflow that prevents merge when the PR has unresolved review comments or has not received the required number of approvals. Use a status check that reads the GitHub API review state and fails until both conditions are met.

Docker, Deployment, and Release Automation (Prompts 19-50)

Prompt 19: Write a GitHub Actions workflow that builds a Docker image, tags it with the git SHA and latest, pushes it to GitHub Container Registry (ghcr.io), and signs it using cosign for supply chain security. Trigger on push to main only.

Prompt 20: Create a GitHub Actions workflow that deploys a Node.js application to an AWS EC2 instance. On push to main, SSH into the EC2 instance using a stored SSH private key secret, pull the latest code, install dependencies, run the build, and reload PM2. Show how to store the EC2 host as a secret and use it in the SSH command. Prompt 21: Write a GitHub Actions workflow that deploys a Docker container to AWS ECS. Build the Docker image, push it to ECR, update the ECS task definition with the new image tag, register the new task definition, and update the ECS service to deploy it. Use OIDC authentication to AWS instead of long-lived access keys.

  • Prompt 22: Create a GitHub Actions workflow that deploys a Next.js application to Vercel. Install the Vercel CLI, pull environment variables from Vercel for the correct environment, build and deploy using vercel deploy --prebuilt, and set the deployment URL as a PR comment.
  • Prompt 23: Write a GitHub Actions workflow that deploys a Lambda function. Package the function code into a zip, use the AWS CLI to update the function code, publish a new version, update the production alias to point to the new version, and run a smoke test by invoking the Lambda with a test payload.
  • Prompt 24: Create a GitHub Actions release workflow triggered by a git tag push. Build the project, create a GitHub Release using the tag as the version, generate release notes from the commit log since the last tag, attach build artifacts to the release, and publish the npm package.
  • Prompt 25: Write a GitHub Actions workflow that uses environments for staging and production deployments with approval gates. The staging deployment runs automatically on push to main. The production deployment is triggered from the staging environment and requires a manual approval from a team member before proceeding.
  • Prompt 26: Create a GitHub Actions workflow that runs a database migration before deploying the application. Use the depends-on key to ensure the migration job runs and succeeds before the deployment job starts. Roll back the migration if the deployment fails using an on-failure step.
  • Prompt 27: Write a GitHub Actions workflow that sends a Slack notification when a deployment succeeds or fails. Include the deployment environment, the deploying user, the commit SHA and message, and a link to the workflow run. Use the Slack API with a bot token stored as a secret.
  • Prompt 28: Create a GitHub Actions OIDC authentication setup for AWS. Configure the identity provider in AWS IAM, define an IAM role with a trust policy that allows the specific GitHub repo and branch, and show the workflow step that calls aws-actions/configure-aws-credentials with the role ARN instead of static access keys.

FAQ

How do I store secrets in GitHub Actions?

Go to your repository Settings, then Secrets and variables, then Actions. Add repository secrets for values used in all branches and environments. Add environment secrets for values scoped to specific deployment environments (staging, production). Reference secrets in workflows as ${{ secrets.SECRET_NAME }}. Never hardcode secrets in workflow files or print them in logs — GitHub Actions automatically redacts known secret values from logs, but you should still avoid explicit logging of secret values.

How do I speed up slow GitHub Actions workflows?

Cache dependencies between runs (actions/cache for npm, pip, go modules). Run independent jobs in parallel rather than sequentially. Use concurrency groups to cancel superseded runs. Split a slow test suite into parallel shards using matrix strategy. Use larger runners (4 or 8 core) for CPU-bound tasks. Use OIDC for AWS authentication instead of API calls to fetch credentials. Most workflows can be brought under 5 minutes with these techniques.

What is the difference between GitHub Actions jobs and steps?

A job is a group of steps that run on the same runner machine. Jobs run in parallel by default and require explicit needs dependencies to run sequentially. Steps are individual shell commands or action calls within a job. Steps in the same job share the file system. Steps in different jobs do not share the file system — you must use artifacts to pass files between jobs. Use multiple jobs when tasks can run in parallel or need different runner environments (e.g., test on Linux and Windows).

Are GitHub Actions minutes free?

Public repositories get unlimited free minutes on GitHub-hosted runners. Private repositories get 2000 free minutes per month on the free plan, more on paid plans. Ubuntu runners use 1x the minute multiplier; Windows runners use 2x; macOS runners use 10x. Self-hosted runners are free for all plans and do not consume GitHub minutes — useful for high-volume private repos or for runners with specific hardware requirements like ARM or GPU.

Related free tools

If you want to turn this topic into action, use one of ShortIQ's free tools for campaign planning, UTM structure, or QR distribution.

Continue Reading

Explore more guides on link shortener SaaS strategy, Bitly alternatives, and white label link management.

Free newsletter

Get new guides in your inbox

We publish practical guides on dev tooling, prompt engineering, marketing workflows, and deployment. No fluff — straight to the point.

No spam. Unsubscribe any time.

Was this article helpful?

Tell us if this guide solved the problem or what was still missing. We use this to improve the blog and only follow up if you explicitly allow it.

We use this to improve tutorials, examples, and technical depth.