Auto-promote green draft PRs to ready-for-review

[accuser]

Automates the draft → review pipeline: a draft PR whose CI run goes green is marked ready for review automatically, which hands it straight to the existing Claude PR Review workflow.

What changed

New .github/workflows/auto-ready.yml — listens via workflow_run for the CI workflow completing. When the completed run is a pull_request run that succeeded, it finds the open draft PR whose head still points at the exact SHA that went green, marks it ready for review (gh pr ready), and dispatches claude-pr-review.yml for it.

Promotion is deliberately scoped. A draft is flipped only when all of these hold:

• the CI run succeeded (run-level success subsumes ci-green);
• the head branch lives in this repo — fork drafts are never touched;
• the PR is still open, still draft, and its head SHA equals the green SHA (a push racing the promotion keeps it draft; the newer run promotes if it also passes);
• it isn't a Dependabot PR;
• it doesn't carry a keep-draft label — the opt-out for work that should stay draft while green (spikes, stacked PRs). Creating that label in the repo is optional but recommended for discoverability.

claude-pr-review.yml — gains a workflow_dispatch trigger with a pr_number input, and resolves its concurrency group, checkout ref (refs/pull/N/merge), and prompt PR number from either event shape. The ready_for_review trigger is unchanged, so manually marking a draft ready still works exactly as before.

Why the explicit dispatch (the load-bearing detail)

Events caused by the default GITHUB_TOKEN never start workflow runs. If auto-ready just marked the PR ready, the ready_for_review event would fire but claude-pr-review.yml would silently never run — breaking the very pipeline this exists to close. workflow_dispatch is GitHub's documented exception to that rule, so auto-ready invokes the review by name after flipping the PR. A side benefit: maintainers get a manual "re-review this PR" button in the Actions tab, which the run-once review discipline previously lacked.

Why a separate workflow rather than a job in ci.yml

• ci-green's hand-maintained gate audit would need an EXEMPT entry, tangling promotion into the required check's job graph;
• the promotion needs pull-requests: write + actions: write, while ci.yml is least-privilege contents: read and runs untrusted project code — auto-ready checks out nothing and runs no project code, so the write scopes never coexist with anything a PR author controls;
• run-level conclusion == 'success' is exactly "the whole CI run passed" (marginally stricter than ci-green alone: a red report-only coverage job also holds the draft, a safe default).

Notes for testing

• workflow_run workflows only fire from the default branch, so auto-ready cannot be exercised from this PR — first observable run is the first draft PR that goes green after merge.
• Both files pass YAML validation; the jq PR-filter was exercised against fixture payloads covering all five skip/promote cases.
• Pure CI/infra change, so no design/pending/ increment file, per the release-discipline rule.

🤖 Generated with Claude Code

https://claude.ai/code/session_017Zawz3rjApepiGgFdu7ufn

---

Generated by Claude Code

[accuser]

Heads-up on the missing review: marking this PR ready did fire the Claude PR Review workflow (run — so the edited ready_for_review path works), but claude-code-action skipped itself with:

Workflow validation failed. The workflow file must exist and have identical content to the version on the repository's default branch. […] this is normal and you should ignore this error.

That's the action's built-in guard against a PR modifying the review workflow to hijack its credentials — and this PR modifies claude-pr-review.yml, so it applies here by definition. Reviews resume as normal once this merges; the guard cannot be (and shouldn't be) worked around from the PR itself.

Everything else is green: all 29 checks passed on c928885, including CI green, and the branch is conflict-free.

---

Generated by Claude Code