Keep non-required checks off the GitHub Actions critical path

Genuinely advisory checks (a bundle-size comment, a preview deploy, a non-blocking lint annotation) don't rerun on every push and don't gate the merge. They run once per PR, or post asynchronously, so they inform without adding to the wait. Real tests and build validation stay on every push, for those, the lever is to make them faster, not to stop running them.12

# A size-diff comment is advisory: run it on open/ready, not on every push.
#
# Keep "reopened". The DEFAULT types are [opened, synchronize, reopened], and naming
# any types replaces that list wholesale: drop reopened and a PR that is closed and
# reopened never runs the check again. What you are removing here is "synchronize",
# the every-push trigger. That is the whole point.
on:
  pull_request:
    types: [opened, ready_for_review, reopened]   # note: no "synchronize"

The advisory check reruns on every push and sits on the critical path with no gating value.

on:
  pull_request:   # the size-diff comment reruns on every push and sits on
                  #   the critical path, even though no one merges on it

The slowest check holding up a PR is sometimes one that isn't even required to merge. If it's purely advisory, running it on every push is friction with no gating value. The critical distinction: a non-required check that runs real tests or validates a build is still load-bearing developer signal, de-scoping that hides failures. Only narrow checks whose output is genuinely advisory, and if you can't confirm a check is non-required (branch-protection data is unreadable), leave it alone.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to audit and fix this practice in your own repo.

Inspect this repo's .github/workflows for a check that sits high on the PR critical path but is purely advisory (a bundle-size comment, a preview deploy, a non-blocking annotation) and is not required to merge. For a genuinely advisory check, narrow its trigger so it does not rerun on every push (for example `types: [opened, ready_for_review, reopened]`, which drops only `synchronize`). Keep `reopened`: naming any `types` replaces the default list wholesale, so omitting it means the check never runs again on a reopened PR, or make it post asynchronously. Do NOT de-scope any check that runs tests, validates a build, feeds a required aggregator, or whose required status you cannot confirm: for a real gate the fix is to make it faster, not to stop running it. Show me the diff and open a PR rather than applying it blindly.

Ground these changes in the upstream docs before you edit: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows, https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks. If you cannot fetch them, say so rather than guessing, and cite what you used in the PR description.

If you do not know why a run is slow yet, start with the diagnostic guide. Let an agent find which of these applies: /ci-speedup. If your workflows are already optimized but still slow, see our guide to fast GitHub Actions and GitHub Actions runner alternatives. Building containers in CI? The Docker workflow guide covers layer caching end to end. Want to see how your configuration measures up before changing anything? CI Score grades workflow config against a pass/fail rubric of these practices. It is not a speed measurement. To find exploitable workflow paths before attackers do, ci-secure checks the ten critical GitHub Actions attack vectors and lets you choose which fixes to apply.

• GitHub Actions too slow
• Fast GitHub Actions
• GitHub Actions alternatives
• GitHub Actions pricing
• Self-hosted GitHub Actions runners
• Docker CI on GitHub Actions
• Install the free /ci-score skill to improve your GitHub Actions setup
• Install the /ci-secure skill to close critical attack vectors in GitHub Actions
• Browse GitHub Actions agent skills