Wait until a draft is ready for expensive checks

Avoid spending runner time on expensive validation until a draft pull request becomes ready for review.

Prompt

Evaluate and apply this CI technique to my repository: Wait until a draft is ready for expensive checks.

Avoid spending runner time on expensive validation until a draft pull request becomes ready for review.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/defer-draft-work.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How companies used this technique

Read what each company changed and follow the original sources.

Run expensive checks when a draft becomes ready

Checkout Kit skips its change-detection job, and so every platform job behind it, while a pull request is a draft. Adding ready_for_review to the trigger types starts a full run as soon as the draft is marked ready.

Merged 2026-06-16; both lines are on the default branch. Source

Use it when: Developers push to draft pull requests many times before asking for review.
Before applying it: Without ready_for_review, a draft promoted to ready keeps its skipped result on an untested commit.

Wait until a draft is ready for expensive checks

SubmitQueue added draft guards to every CI job and its required aggregate, then added ready_for_review to the workflow events. Pushes to main and merge-queue runs keep their validation.

Drafts skip the full suite, and it runs when the pull request is marked ready for review. Source

Use it when: Drafts receive frequent exploratory commits and your team agrees that expensive checks can wait.
Before applying it: Drafts get feedback later, so agree on it as a team policy. Test draft, ready, reopened, main and merge-queue events so every required check still reports.

How companies used this technique

Run expensive checks when a draft becomes ready

Wait until a draft is ready for expensive checks

Related techniques

Cancel superseded pull request runs

Package once, and build full installers after merge

Reduce the setup floor before increasing shard count

Company Playbooks

Related guides

Cancel superseded CI runs

Build and test only what changed

Cut CI queue time

Filter workflows by changed files

Bound runner jobs with timeouts

Right-size GitHub Actions runners