“Why is CI so slow?” usually has its answer buried in the YAML, but no one wants to read 600 lines of it. A good pipeline-audit prompt names the dimensions (cache, parallelism, secrets, gates), demands evidence from the actual logs, and returns a ranked action list instead of vibes. Below are 12 templates you can paste into Claude Opus 4.7, GPT-5.5, or Gemini 3.1 Pro alongside your workflow file.
TL;DR
- Paste your workflow YAML plus a recent run log into one of the 12 prompts below. A 1M-token model (Opus 4.7, Sonnet 4.6, Gemini 3.1 Pro) swallows even a multi-file
.github/workflows/directory in one shot. - Audit five things in order: runtime, cache hit rate, parallelism, gate honesty, and secrets exposure.
- The biggest wins in 2026 are path filters and content-hashed cache keys, not faster runners — GitHub cut hosted-runner prices up to 39% in January 2026, so compute is rarely the bottleneck.
- Never let AI auto-apply changes to gates or secrets. Draft yes, merge after human review.
Who this is for
Platform engineers, tech leads tired of 25-minute CI, founders trying to ship faster, and anyone who has watched a CI bill grow faster than the team. If you maintain GitHub Actions, GitLab CI, or CircleCI, every prompt here applies.
When not to use these prompts
Skip them on a pipeline with no tests — an audit can’t fix a missing concept. And don’t apply any tweak without a runtime baseline first; otherwise you can’t tell whether a change helped.
What a pipeline audit prompt needs
Every template below carries six elements. If you write your own, keep all six:
- Role — who the AI plays (SRE, release captain, staff engineer, QA lead).
- Context — stack, branch, failing logs, the diff, a dashboard URL.
- Goal — one concrete deliverable: root cause, checklist, plan, ticket list, or runbook.
- Constraints — what the AI must NOT do (no auto-fix, no invented file paths).
- Output format — numbered findings, a markdown table, JSON, a unified diff, or runnable code.
- Signal — one or two examples of “good” output, or a counter-example.
Which model to run these in
| Model (June 2026) | Context | Why for CI audits | API $/1M (in/out) |
|---|---|---|---|
| Claude Opus 4.7 | 1M tokens | Top SWE-bench Verified (87.6%); best at multi-file YAML reasoning | 5 / 25 |
| Claude Sonnet 4.6 | 1M tokens | Fast workhorse; cheaper for bulk audits | 3 / 15 |
| Gemini 3.1 Pro | 1M tokens | Strong long-context recall across many workflow files | 2 / 12 |
| GPT-5.5 | ~320 pages in-app (Plus) | Best terminal/agentic scores (Terminal-Bench 2.0 82.7%) | 5 / 30 |
For a whole .github/workflows/ folder plus run logs, any of the three 1M-token models reads it in one pass. On a ChatGPT Plus ($20/mo) account the in-app window is roughly 320 pages, so split very large logs or move to the API.
12 copy-ready prompt templates
Swap the [bracketed] placeholders before sending.
1. End-to-end pipeline audit
You are a platform engineer. Audit this `[filename]` for: (1) total runtime + biggest single step, (2) cache hit-rate signals (missing keys, stale paths), (3) parallelism opportunities, (4) gates that warn but don't fail, (5) secrets exposure. Output a ranked action list with the estimated minutes or risk saved per item.Swap: [filename] — e.g. .github/workflows/ci.yml.
2. Cache audit
Audit caching for this pipeline. For each cache step: (1) is the cache key content-hash based or static? (2) does the path actually cover the heavy install? (3) are restore-keys listed for partial hits? (4) what is the TTL / invalidation strategy? Output one fix per cache step.3. Parallelism audit
Find parallelism opportunities: (1) jobs that needlessly `needs:` another, (2) tests that could shard, (3) build + lint + typecheck running sequentially when they could run in parallel, (4) matrix entries that don't need full coverage. Output a YAML diff.4. Gate honesty audit
Audit gates: which steps set `continue-on-error: true`, use `if: always()`, or report success while the underlying tool failed? Output a table: step | currently | should be | severity. Flag any gate that has masked a real failure.5. Secrets / OIDC audit
Audit secret handling: (1) long-lived secrets that could move to OIDC, (2) secrets used in `echo` or step output, (3) PRs from forks with access to secrets, (4) secret names that leak their purpose. Output a remediation list ordered by exposure risk.6. Self-hosted vs managed decision
We currently use [provider]. Decide whether to add self-hosted runners for: (1) heavy CPU steps (build, e2e), (2) steps needing a custom OS, (3) steps that hit a private network. For each, give a cost / maintenance estimate and a recommendation.Swap: [provider] — GitHub Actions / GitLab CI / CircleCI.
7. Build matrix audit
Audit the build matrix: (1) are all combinations necessary, or do some only catch known issues? (2) could we run only `node-lts` on PRs and the full matrix on main? (3) are deprecated versions still tested? Output a trimmed matrix.8. Required vs blocking checks
List which checks are currently REQUIRED by branch protection. Decide for each: keep / move to optional / remove. Criteria: false-positive rate, runtime, redundancy with another check. Output a table.9. Bill audit
Our CI costs [monthlyCost] per month on [provider]. Audit for spend: (1) top 3 jobs by minutes, (2) % of runs cancelled mid-way, (3) PR-triggered runs that could be path-filtered, (4) cron jobs running too often. Output the top 3 savings with estimated minutes recovered.Swap: [monthlyCost], [provider].
10. Path-filter opportunities
Find path-filter opportunities: (1) frontend-only PRs that don't need backend tests, (2) docs-only PRs running full e2e, (3) mobile changes triggering the web pipeline. Output `paths:` blocks per workflow.11. Reusable workflow extraction
Identify steps repeated across 3+ workflows that could become a reusable workflow or composite action: (1) setup (node + pnpm + cache), (2) lint, (3) test reporters, (4) deploy. Output the refactor plan plus the reusable workflow stub.12. PR-impact heatmap
For the last 50 PRs, count how often each pipeline job ran AND whether it actually exercised the changed files. Identify the top 3 jobs that ran on PRs they couldn't fail. Output a path-filter or conditional to skip them.2026 runner costs (so you can sanity-check the audit)
When a prompt estimates “minutes saved,” convert to money with current rates. Prices as of June 2026:
| Provider | Free tier (private repos) | Default per-minute | Notes |
|---|---|---|---|
| GitHub Actions (Linux 2-core) | 2,000 min/mo (Free), 3,000 (Team) | $0.006 | Hosted prices cut up to 39% in Jan 2026; 16-core Linux now $0.042/min |
| GitHub Actions (macOS) | counted against the same quota | $0.062 | macOS minutes burn quota ~10x faster than Linux |
| GitLab CI | 400 min/mo (Free), 10,000/user (Premium $29) | $0.010 | Extra minutes billed at $10 per 1,000 |
| CircleCI | 30,000 credits/mo (Free) | $0.006 (Medium Linux, 10 credits/min) | ~3,000 Medium-Linux minutes on the free tier |
Public repositories run free on all three. GitHub’s proposed per-minute fee for self-hosted runners was postponed after community pushback, so self-hosted usage on GitHub stays free as of June 2026 — verify on the GitHub Actions runner pricing page before you model a migration.
Common mistakes
- Caching
node_modulesdirectly — slow to restore and breaks across operating systems. Cache the package manager store instead. - Running the full e2e suite on every PR.
continue-on-error: trueon tests “so they don’t block” — this is how green lies.- PRs from forks with secret access, a common credential-leak path.
- No path filters, so every PR runs every job.
- Self-hosted runners with no managed lifecycle, a real security risk.
- A full matrix on every PR; reserve it for main and release branches.
How to push results further
- Content-hash your cache keys off the lockfile and
package.json. - Use OIDC instead of long-lived cloud secrets wherever the provider supports it.
- Split required vs optional checks deliberately — required equals a trust signal.
- Path filters cut spend more than runner upgrades, especially now that hosted compute got cheaper.
- Reusable workflows remove duplication and centralize security patches.
- Track CI minutes per PR to surface flake-fix candidates.
- Fail fast: order cheap checks (lint, typecheck) before expensive ones (e2e).
FAQ
- When should I move to self-hosted runners? When managed cost exceeds self-hosted maintenance AND you need custom hardware or private-network access. After the January 2026 hosted price cuts (16-core Linux at $0.042/min), the math favors managed more often than it did in 2025.
- How fast should CI be? Under 10 minutes on a typical PR. Beyond that, developer behavior degrades and people stop waiting for green.
- Is the GitHub Actions cache reliable? Yes, but cache keys must be deterministic. Avoid date-based keys; hash the lockfile instead.
- Can AI write the whole pipeline? Draft yes, ship-as-is no. Always review security boundaries and secret handling before merging.
- What about Docker layer caching? Useful for image builds — push the cache to a registry, not just local Docker, so runners can actually reuse it.
- How do I detect false-green CI? Run template 4 (gate honesty) and grep the YAML for
continue-on-errorand|| true.