30 Claude Prompts for GitHub Actions

You are a senior DevOps engineer who designs test matrices for open source libraries. <context> I maintain a library that needs to be tested across multiple language versions and operating systems before every release. </context> <inputs> - Language versions to support: [E.G. NODE 18, 20, 22] - Operating systems to test: [E.G. UBUNTU, MACOS, WINDOWS] - Test command: [TEST COMMAND] - Any known incompatible combination: [E.G. VERSION X DOES NOT SUPPORT WINDOWS] </inputs> <task> Write a GitHub Actions matrix strategy that tests every valid combination of language version and operating system, excluding the known incompatible combination. </task> <constraints> Use the "exclude" key correctly rather than manually listing every valid combination. Set fail-fast to false so one failing combination does not cancel the others. Keep runner minutes in mind, note the total job count the matrix produces. </constraints> <format> Return the matrix YAML block, then a one-line total: "This matrix runs [NUMBER] jobs." </format>

You are a senior DevOps engineer who builds dynamic CI pipelines. <context> I need my matrix values to come from a file in the repo instead of being hardcoded in the workflow, because the list of supported targets changes often. </context> <inputs> - Where the list lives: [E.G. A JSON FILE AT CONFIG/TARGETS.JSON] - Format of that file: [PASTE A SAMPLE OF THE FILE CONTENTS] - What the matrix job should do with each value: [E.G. BUILD A DOCKER IMAGE PER TARGET] </inputs> <task> Write a workflow with a setup job that reads the file, sets a JSON output, and a second job whose matrix is populated dynamically from that output using fromJSON. </task> <constraints> Handle the case where the file is malformed or missing by failing the setup job with a clear error message. Do not use a third-party action for the JSON parsing, use built-in expressions. Explain the output-passing mechanism in one sentence. </constraints> <format> Return the full two-job YAML in one code block, then one sentence explaining how the output flows from job one to job two. </format>

You are a senior DevOps engineer who debugs flaky and inconsistent CI failures. <context> My matrix build passes on most combinations but consistently fails on one specific version and operating system pairing, and the error log is not obviously helpful. </context> <inputs> - Failing combination: [E.G. NODE 18 ON WINDOWS] - Error output from that job: [PASTE THE LOG SNIPPET] - Passing combination for comparison: [E.G. NODE 18 ON UBUNTU] </inputs> <task> Analyze the error log and identify the most likely root cause given that it only fails on this one combination, then propose a fix. </task> <constraints> Consider path separator differences, line ending differences, and version-specific dependency behavior as likely candidates before anything exotic. Do not suggest disabling the failing combination as the primary fix, that is a last resort only. Be specific about which file or step to change. </constraints> <format> Return a "Most likely cause" paragraph, then a "Fix" section with the exact change to make, then a fallback option if the fix does not resolve it. </format>

You are a senior DevOps engineer who manages CI infrastructure costs for a growing engineering team. <context> Our matrix build is spinning up too many parallel jobs at once and we are hitting our concurrent runner limit, causing queued builds to time out. </context> <inputs> - Current matrix size: [NUMBER OF COMBINATIONS] - Runner plan limit: [MAX CONCURRENT RUNNERS, E.G. 20] - Priority order if jobs must be limited: [E.G. LINUX FIRST, THEN MACOS, THEN WINDOWS] </inputs> <task> Add a max-parallel setting to the matrix strategy and a concurrency group at the workflow level so that redundant runs on the same branch cancel each other instead of queueing. </task> <constraints> Explain the tradeoff between lower max-parallel and total pipeline duration in one sentence. Use a concurrency group keyed on the branch and workflow name so unrelated branches are not affected. Do not cancel in-progress runs on the default branch. </constraints> <format> Return the updated YAML snippet showing the strategy and concurrency blocks, followed by a one-sentence tradeoff explanation. </format>

You are a senior DevOps engineer who documents CI coverage for open source maintainers. <context> Maintainers keep asking which language versions and platforms my library is actually tested against, and I want that documented clearly instead of answering the same question repeatedly. </context> <inputs> - Matrix combinations currently tested: [PASTE THE MATRIX FROM YOUR WORKFLOW] - README section this should go under: [E.G. COMPATIBILITY] - Preferred format: [TABLE OR BADGE LIST] </inputs> <task> Generate a README section that documents exactly which combinations are tested in CI, derived directly from the matrix definition I provided. </task> <constraints> Do not claim support for any combination not actually present in the matrix. If badges are requested, use shields.io static badge syntax, not a service that requires an API key. Keep the section under 20 lines of markdown. </constraints> <format> Return a single markdown code block ready to paste into the README, with a short comment noting it should be regenerated whenever the matrix changes. </format>

You are a senior DevOps engineer who optimizes CI pipeline runtime. <context> My workflow reinstalls dependencies from scratch on every run and the install step alone takes several minutes, slowing down every pull request. </context> <inputs> - Package manager: [NPM, YARN, PNPM, PIP, MAVEN, ETC.] - Lockfile name: [E.G. PACKAGE-LOCK.JSON] - Current install step: [PASTE THE RELEVANT YAML STEP] </inputs> <task> Add a caching step using actions/cache that keys off the lockfile hash, so dependencies are restored instantly when the lockfile has not changed. </task> <constraints> Use a cache key that includes the OS and lockfile hash, with a restore-keys fallback for partial matches. Cache the correct directory for the specified package manager, not a guessed path. Explain in one sentence what happens on a cache miss versus a cache hit. </constraints> <format> Return the updated YAML step in one code block, then a one-sentence explanation of the hit versus miss behavior. </format>

You are a senior DevOps engineer who optimizes multi-job CI pipelines. <context> My pipeline has a build job followed by separate test and deploy jobs, and right now each downstream job rebuilds the project from scratch instead of reusing the build output. </context> <inputs> - Build output folder: [E.G. DIST OR BUILD] - Job names involved: [E.G. BUILD, TEST, DEPLOY] - Build command: [BUILD COMMAND] </inputs> <task> Set up the build job to upload the build output as an artifact and have the downstream jobs download it instead of rebuilding, using actions/upload-artifact and actions/download-artifact. </task> <constraints> Set a reasonable artifact retention period, do not leave it at the maximum default if the artifact is only needed within the same run. Explain why artifacts are the correct tool here rather than actions/cache. Keep the diff minimal against the existing jobs. </constraints> <format> Return the updated YAML for all three jobs in one code block, then one sentence on why artifacts, not cache, are correct for this case. </format>

You are a senior DevOps engineer who debugs CI caching problems. <context> I added a cache step to my workflow weeks ago but every run still shows a cache miss in the logs, and dependency install times have not improved at all. </context> <inputs> - Current cache step: [PASTE THE CACHE STEP YAML] - Cache key expression used: [PASTE THE KEY LINE] - What the Actions logs say about the cache: [PASTE THE RELEVANT LOG LINES] </inputs> <task> Identify why the cache is never matching and provide the corrected cache step. </task> <constraints> Check for common causes first: a key that includes a value that changes every run such as a timestamp or run ID, a path that does not match where the package manager actually stores files, or a restore-keys prefix that never matches the key format. Be specific about which cause applies here. </constraints> <format> Return a "Root cause" sentence, then the corrected YAML step in one code block. </format>

You are a senior DevOps engineer who optimizes Docker builds inside CI pipelines. <context> We build a Docker image in CI on every push and each build takes several minutes because Docker layer caching is not persisting between runs. </context> <inputs> - Dockerfile location: [E.G. ROOT DOCKERFILE] - Build tool currently used: [DOCKER BUILD, DOCKER BUILDX, OR OTHER] - Image registry destination: [E.G. GHCR OR DOCKER HUB] </inputs> <task> Set up Docker Buildx with GitHub Actions cache backend so image layers persist between workflow runs and only changed layers rebuild. </task> <constraints> Use the type=gha cache backend, not a manual actions/cache workaround, since it handles Docker layers correctly. Include the buildx setup step and the login step for the target registry using secrets, not hardcoded credentials. Note the expected cache size growth over time. </constraints> <format> Return the full workflow YAML in one code block, then one sentence noting how to monitor cache size growth. </format>

You are a senior DevOps engineer who reports on CI performance improvements to engineering leadership. <context> I made caching changes to our pipeline and I need to show the actual time savings to justify the work to my manager. </context> <inputs> - Average run time before the change: [MINUTES, FROM ACTIONS HISTORY] - Average run time after the change: [MINUTES, FROM ACTIONS HISTORY] - Number of workflow runs per week: [NUMBER] - Runner cost per minute if known: [COST OR "UNKNOWN"] </inputs> <task> Calculate the time saved per run, the weekly time saved across all runs, and if cost per minute is known, the estimated monthly cost savings. </task> <constraints> Show the arithmetic, do not just state a final number. If cost per minute is unknown, state the savings in minutes and developer wait time only, do not invent a cost figure. Keep the summary short enough to paste into a Slack message. </constraints> <format> Return a short paragraph with the calculation shown, followed by a one-line summary suitable for Slack, like "Saves X minutes per week across Y runs." </format>

You are a senior release engineer who automates versioning for software projects. <context> Every release, someone on my team manually bumps the version number and writes the changelog by hand, and it is inconsistent and often forgotten. </context> <inputs> - Versioning scheme: [SEMVER OR OTHER] - Commit message convention in use: [CONVENTIONAL COMMITS OR "NONE"] - Changelog file location: [E.G. CHANGELOG.MD] - Bot account name to use for the commit: [E.G. RELEASE-BOT] </inputs> <task> Write a GitHub Actions workflow that runs on merge to the main branch, determines the next version based on the commit convention, updates the changelog file, and commits the result back to the repo. </task> <constraints> If conventional commits are not in use, propose the simplest alternative such as a manual version input via workflow_dispatch instead of guessing intent from commit messages. Use a bot commit identity, not a personal account, for the automated commit. Avoid triggering an infinite loop where the bot commit re-triggers the same workflow. </constraints> <format> Return the workflow YAML in one code block, then a short note on how the infinite-loop trigger is avoided. </format>

You are a senior release engineer who automates GitHub release publishing. <context> We tag releases manually in git but nobody creates the actual GitHub Release page with notes, so users checking the Releases tab see nothing useful. </context> <inputs> - Tag format used: [E.G. V1.2.3] - Where release notes content should come from: [CHANGELOG FILE, AUTO-GENERATED FROM COMMITS, OR PR TITLES] - Whether to attach build artifacts: [YES OR NO, AND WHICH FILES] </inputs> <task> Write a workflow triggered on tag push that creates a GitHub Release using the specified notes source, and attaches build artifacts if requested. </task> <constraints> Use the softprops/action-gh-release action or GitHub's built-in generate_release_notes option, pick whichever fits the notes source given and explain the choice. Ensure the workflow only runs on tags matching the specified format, not on every push. Use the automatically provided GITHUB_TOKEN, do not ask for a separate personal access token unless artifacts require cross-repo access. </constraints> <format> Return the workflow YAML in one code block, then one sentence explaining which release-notes method was chosen and why. </format>

You are a senior release engineer who designs staged rollout pipelines. <context> We want to deploy every merge to main to a canary environment automatically, but only promote to production when someone manually approves it. </context> <inputs> - Canary environment name: [E.G. STAGING] - Production environment name: [E.G. PRODUCTION] - Deploy command or script: [DEPLOY COMMAND] - Who should approve production deploys: [TEAM OR USERNAME] </inputs> <task> Write a workflow with a canary deploy job that runs automatically on merge to main, followed by a production deploy job that requires manual approval using GitHub environments with required reviewers. </task> <constraints> Use GitHub Environments with protection rules for the approval gate, not a third-party approval action. Make the production job depend on the canary job succeeding first. State clearly in a comment where the environment protection rule itself needs to be configured in repo settings, since that part cannot be expressed in YAML alone. </constraints> <format> Return the workflow YAML in one code block, with a comment block at the top listing the manual repo settings steps required. </format>

You are a senior release engineer who automates package publishing. <context> We publish a package to a registry after every release and it is currently a manual command someone runs from their laptop, which is error-prone and inconsistent. </context> <inputs> - Registry: [NPM, PYPI, DOCKER HUB, GHCR, ETC.] - Trigger condition: [E.G. ON GITHUB RELEASE PUBLISHED] - Auth method: [E.G. NPM_TOKEN SECRET OR OIDC TRUSTED PUBLISHING] </inputs> <task> Write a workflow that publishes the package to the specified registry when the trigger condition fires, using the specified authentication method. </task> <constraints> If OIDC trusted publishing is available for the registry, prefer it over a long-lived token secret and explain the setup step needed on the registry side. Include a build and test step before publish so a broken build never gets published. Never print or log the auth token value. </constraints> <format> Return the workflow YAML in one code block, then a short "Registry-side setup" note if OIDC or trusted publishing requires configuration outside GitHub. </format>

You are a senior release engineer who builds safety nets for automated deployments. <context> We deploy automatically on merge and occasionally ship something that breaks production, and right now rollback is a manual scramble. </context> <inputs> - Deploy target: [E.G. KUBERNETES, ECS, A PLATFORM LIKE RENDER OR FLY] - Health check endpoint or command: [ENDPOINT URL OR COMMAND] - How rollback is performed today, manually: [DESCRIBE THE MANUAL STEPS] </inputs> <task> Add a post-deploy health check step to the workflow that polls the health check endpoint for a defined window, and automatically triggers the described rollback steps if the check fails. </task> <constraints> Use a bounded retry loop with a timeout, do not poll forever. Send a notification, such as a Slack message or GitHub issue comment, when an automatic rollback fires, so the team knows it happened. Keep the health check window realistic, not so short that a slow-starting service triggers a false rollback. </constraints> <format> Return the updated workflow YAML in one code block, then one sentence on how the team gets notified when rollback triggers. </format>

You are a senior application security engineer who reviews CI pipeline configurations. <context> I want a security review of a GitHub Actions workflow before it goes live, since it has access to deployment secrets. </context> <inputs> - Workflow file contents: [PASTE FULL YAML HERE] - Secrets referenced: [LIST SECRET NAMES USED, NOT VALUES] - Does it run on pull requests from forks: [YES OR NO] </inputs> <task> Review the workflow for security issues including overly broad permissions, unpinned third-party actions, secrets exposed to untrusted pull request triggers, and script injection risks from user-controlled input like PR titles or branch names. </task> <constraints> Rank findings by severity, do not present a flat list. For each finding, name the specific line or step, not a vague category. If nothing is wrong in a category, say so explicitly rather than omitting it. </constraints> <format> Return a table with columns Severity, Finding, Location, Fix. Follow it with a one-paragraph overall risk summary. </format>

You are a senior application security engineer who hardens CI supply chains. <context> Our workflows reference third-party GitHub Actions by version tag like @v3, and I want them pinned to a specific commit SHA to prevent a supply chain attack from a compromised tag. </context> <inputs> - Workflow file with actions to pin: [PASTE FULL YAML HERE] - Actions that must be updated: [LIST THE ACTION NAMES, OR "ALL THIRD PARTY ACTIONS"] - Team policy on pinning GitHub-owned actions: [PIN EVERYTHING OR EXEMPT OFFICIAL ACTIONS] </inputs> <task> Rewrite the workflow with every third-party action reference pinned to a full commit SHA instead of a mutable tag, keeping the version tag as a trailing comment for readability. </task> <constraints> Do not pin actions published by GitHub itself, such as actions/checkout, more strictly than the team's actual policy requires, note this as a judgment call rather than pinning everything blindly if that policy is unclear. Explain in one sentence how to find the correct commit SHA for a given tag. Do not invent SHA values, mark them as [SHA TO CONFIRM] where you have not verified one. </constraints> <format> Return the updated YAML in one code block, then one sentence explaining how to look up and verify each SHA before merging. </format>

You are a senior application security engineer who enforces least-privilege access in CI. <context> Our workflows use the default GITHUB_TOKEN permissions, which grant broad read and write access, and I want to scope each workflow down to only what it actually needs. </context> <inputs> - Workflow file contents: [PASTE FULL YAML HERE] - What each job actually does: [E.G. RUNS TESTS, COMMENTS ON PRS, PUBLISHES A RELEASE] - Current default permissions setting, if any: [E.G. NONE SET, OR WRITE-ALL] </inputs> <task> Add an explicit permissions block at the workflow or job level that grants only the scopes each job actually needs, starting from a default of no access. </task> <constraints> Set permissions at the job level when different jobs need different scopes, rather than one broad workflow-level block. Justify each granted scope in a comment next to it. Do not grant write-all or default broad permissions anywhere in the result. </constraints> <format> Return the updated YAML in one code block with inline comments justifying each permission, then a one-line summary of what was removed. </format>

You are a senior application security engineer who audits CI pipelines for injection vulnerabilities. <context> One of our workflow steps directly interpolates a pull request title or branch name into a run: shell command, and I suspect that is a script injection risk. </context> <inputs> - The step in question: [PASTE THE STEP YAML] - What user-controlled value is being interpolated: [E.G. GITHUB.EVENT.PULL_REQUEST.TITLE] - Whether this workflow runs on pull_request or pull_request_target: [TRIGGER TYPE] </inputs> <task> Confirm whether this is an exploitable script injection risk and rewrite the step to safely handle the untrusted value. </task> <constraints> Use an intermediate environment variable set via the env key rather than direct interpolation into the run script, since that is the standard fix for this class of bug. Explain in one or two sentences exactly how the original version could be exploited, with a concrete example payload. Do not just say it is unsafe, show the mechanism. </constraints> <format> Return a "Vulnerability" section with the example exploit payload, then a "Fixed step" section with the corrected YAML in one code block. </format>

You are a senior application security engineer who migrates CI pipelines off long-lived cloud credentials. <context> Our deploy workflow currently authenticates to our cloud provider using a static access key stored as a GitHub secret, and I want to move to short-lived OIDC-based authentication instead. </context> <inputs> - Cloud provider: [AWS, AZURE, OR GCP] - What the workflow currently does with the static key: [E.G. DEPLOYS TO S3, PUSHES TO ECR] - Repo and branch this should be scoped to: [ORG/REPO AND BRANCH NAME] </inputs> <task> Rewrite the workflow to use OIDC federation with the specified cloud provider instead of a static access key, and describe the trust policy configuration needed on the cloud provider side. </task> <constraints> Scope the trust policy to the specific repo and branch given, not to the whole GitHub organization, to prevent any repo from assuming the role. Remove the static key secret from the workflow entirely in the rewritten version. Note that the cloud-side trust policy setup happens outside GitHub and cannot be expressed in the workflow YAML alone. </constraints> <format> Return the updated workflow YAML in one code block, followed by a "Cloud-side setup" section describing the trust policy configuration in plain steps. </format>

You are a senior DevOps engineer who investigates flaky CI failures. <context> A test passes reliably on my local machine but fails intermittently in GitHub Actions, and it is eroding the team's trust in the CI signal. </context> <inputs> - Test name and file: [TEST NAME] - Failure output from CI: [PASTE THE ERROR OUTPUT] - Failure frequency: [E.G. ABOUT 1 IN 5 RUNS] </inputs> <task> Identify the most likely categories of cause for a test that is flaky in CI but stable locally, and propose a diagnostic step for each before proposing a fix. </task> <constraints> Consider timing and race conditions, shared state between parallel test runs, resource limits on the runner, and differences in environment variables or locale between local and CI. Do not recommend simply retrying the test as the final answer, treat retry logic as a stopgap only. </constraints> <format> Return a ranked list of likely causes with a one-line diagnostic step for each, then a separate "Stopgap" note about retry logic if the root cause takes time to fix. </format>

You are a senior DevOps engineer who audits CI pipelines for waste. <context> Our main workflow has grown over a year of small additions and I suspect it now has redundant or unnecessary steps slowing it down. </context> <inputs> - Full workflow file: [PASTE FULL YAML HERE] - Current average run time: [MINUTES] - Runner type in use: [E.G. UBUNTU-LATEST OR A SELF-HOSTED RUNNER] </inputs> <task> Review every step in the workflow and identify steps that are redundant, run unconditionally when they could be conditional, or duplicate work already done in an earlier step. </task> <constraints> Do not remove any step whose purpose is unclear without flagging it for human confirmation first, some steps that look redundant exist for a non-obvious reason. Estimate the time saved by each proposed removal or change where possible. Keep functional behavior identical except for the removed waste. </constraints> <format> Return a table with columns Step, Issue Found, Recommendation, Estimated Time Saved. End with the total estimated time saved. </format>

You are a senior DevOps engineer who designs CI alerting that engineers actually trust. <context> Our CI failures currently send no notification at all, so people only find out a build is broken when someone happens to check, but I also don't want to spam the whole team on every transient failure. </context> <inputs> - Notification channel: [SLACK, EMAIL, OR MICROSOFT TEAMS] - Who or which channel should be notified: [CHANNEL NAME OR TEAM] - Condition for notifying: [E.G. ONLY ON MAIN BRANCH, ONLY AFTER TWO CONSECUTIVE FAILURES] </inputs> <task> Add a notification step that fires under the specified condition, and only on genuine build failures, not on cancelled runs or expected skips. </task> <constraints> Include the failing job name, the branch, and a direct link to the run in the notification message. Use the failure() conditional correctly so cancelled runs do not trigger a false alert. If the condition requires tracking consecutive failures, explain how state is tracked between runs since GitHub Actions has no built-in run history query without an extra step. </constraints> <format> Return the workflow YAML addition in one code block, then one sentence explaining how consecutive-failure tracking works if that condition was requested. </format>

You are a senior DevOps engineer who writes operational documentation for engineering teams. <context> New engineers on my team keep asking the same questions when CI fails, and I want a runbook so they can self-serve instead of pinging me every time. </context> <inputs> - Common failure scenarios we see: [LIST THE RECURRING FAILURES, E.G. FLAKY INTEGRATION TEST, CACHE CORRUPTION, RUNNER TIMEOUT] - Where the workflow files live: [FOLDER PATH] - Who to escalate to if a fix does not resolve it: [PERSON OR TEAM] </inputs> <task> Write a runbook document covering each listed failure scenario, with symptoms, a diagnostic step, a fix, and an escalation path if the fix does not work. </task> <constraints> Write for a mid-level engineer who has never touched this pipeline before, do not assume prior context about our setup. Keep each scenario to one short section, this is a lookup document, not a narrative. Use consistent structure across all scenarios so it is scannable. </constraints> <format> Return a markdown document with one heading per scenario, each containing Symptoms, Diagnose, Fix, and Escalate subsections. </format>

You are a senior DevOps engineer who analyzes CI reliability trends. <context> I exported the recent run history for our main workflow and I want to know if there is a pattern to the failures before I spend time investigating individually. </context> <inputs> - Run history data: [PASTE A LIST OR TABLE OF RECENT RUNS WITH STATUS, DURATION, BRANCH, TIME] - Time period covered: [E.G. LAST 30 DAYS] - Total number of runs in this data set: [NUMBER OF RUNS] </inputs> <task> Analyze the run history for patterns, such as failures clustering on a specific day, branch, time of day, or after a specific type of change, and summarize what you find. </task> <constraints> Only report a pattern if the data actually supports it, do not force a narrative onto noise. State the failure rate as a percentage and compare it to a healthy baseline of under five percent. If the data is too sparse to conclude anything, say so plainly. </constraints> <format> Return a short summary paragraph with the overall failure rate, followed by a bulleted list of any patterns found, or "No clear pattern in this data" if none exist. </format>