Problem
Per discussion on #2149, the needs review label (documented in README) requires admin permission to add — external contributors on fork PRs can't apply it. The label is useful to reviewers for filtering the open-PR list, so we want a path where contributors can signal "ready for review" without admin access.
Proposal
A GitHub Actions workflow that owns the label on the contributor's behalf via slash commands:
pull_request.opened → bot posts a one-time onboarding comment explaining /ready and /wip.issue_comment.created containing /ready on its own line → bot adds the needs review label, reacts 👍 on the comment.issue_comment.created containing /wip on its own line → bot removes the label, reacts 👀.
Works for fork PRs because issue_comment events run in the base-repo context with GITHUB_TOKEN scoped to pull-requests: write + issues: write. No fork-side secrets or contributor permissions required.
Design rationale
- Opt-in over auto-label. Some PRs are intentionally exploratory / not ready; auto-labeling them would noise up the reviewer queue.
- Onboarding comment at PR-open. Teaches the convention at the moment it matters, instead of relying on contributors to have read README/CLAUDE.md.
/ready and /wip are idempotent and reversible. Contributors who mis-fire can correct with the inverse command.- Bot reacts on the triggering comment. Contributors see immediate feedback that their command registered.
Scope
- Single workflow file under
.github/workflows/pr-ready-label.yml.
- No changes to CircleCI.
- No secret configuration —
GITHUB_TOKEN is sufficient.
- Prerequisite: GitHub Actions must be enabled on
adobe/xdm. If it isn't, maintainers need to enable it in repo settings for the workflow to run.
Companion tickets
Non-goals
- Auto-labeling beyond
needs review.
- Replacing any existing CircleCI job.
- A richer slash-command system (Prow-style
/lgtm, /approve, etc.) — out of scope for this PR; can be a follow-up.
PR to follow shortly.
Problem
Per discussion on #2149, the
needs reviewlabel (documented in README) requires admin permission to add — external contributors on fork PRs can't apply it. The label is useful to reviewers for filtering the open-PR list, so we want a path where contributors can signal "ready for review" without admin access.Proposal
A GitHub Actions workflow that owns the label on the contributor's behalf via slash commands:
pull_request.opened→ bot posts a one-time onboarding comment explaining/readyand/wip.issue_comment.createdcontaining/readyon its own line → bot adds theneeds reviewlabel, reacts 👍 on the comment.issue_comment.createdcontaining/wipon its own line → bot removes the label, reacts 👀.Works for fork PRs because
issue_commentevents run in the base-repo context withGITHUB_TOKENscoped topull-requests: write+issues: write. No fork-side secrets or contributor permissions required.Design rationale
/readyand/wipare idempotent and reversible. Contributors who mis-fire can correct with the inverse command.Scope
.github/workflows/pr-ready-label.yml.GITHUB_TOKENis sufficient.adobe/xdm. If it isn't, maintainers need to enable it in repo settings for the workflow to run.Companion tickets
Non-goals
needs review./lgtm,/approve, etc.) — out of scope for this PR; can be a follow-up.PR to follow shortly.