removes ready-for-review label when PR is merged/approved etc.

Signed-off-by: Simon Davies <simongdavies@users.noreply.github.com>

Author: simongdavies

.github/workflows/ready-for-review-label.yml

@@ -0,0 +1,37 @@
+name: Ready-for-review label
+
+# Caller workflow that wires this repository's pull-request events up to the
+# reusable `manage-ready-for-review.yml` workflow, which removes the
+# "ready-for-review" label once a PR is no longer awaiting review.
+#
+# `pull_request_target` (rather than `pull_request`) is required so that the job
+# has a read/write token for pull requests opened from forks. This is safe here
+# because the reusable workflow never checks out or executes pull-request code.
+#
+# The label logic lives in the organisation's `.github` repository so that every
+# repository consumes the same engine. To roll this out to another repository,
+# copy this file verbatim - the `uses:` reference below already points at the
+# shared engine.
+on:
+  pull_request_target:
+    types: [closed, converted_to_draft]
+  pull_request_review:
+    types: [submitted, dismissed]
+
+# Serialise runs per pull request so that concurrent events (for example, a
+# review submitted at the same moment the PR is closed) cannot race on the label.
+concurrency:
+  group: ready-for-review-${{ github.event.pull_request.number }}
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+  pull-requests: read
+  issues: write
+jobs:
+  manage-label:
+    # Shared engine in the org-wide `.github` repository, pinned to a commit SHA
+    # (matching this repository's action-pinning convention).
+    uses: hyperlight-dev/.github/.github/workflows/manage-ready-for-review.yml@8eaae4229db908ea64fff06c31dbf5677611ce5e
+    with:
+      pr-number: ${{ github.event.pull_request.number }}

docs/github-labels.md

@@ -7,6 +7,19 @@ We use GitHub labels to categorize PRs. Before a PR can be merged, it must be as
 - **kind/enhancement** - For PRs that introduce new features or improve existing functionality. This label also applies to improvements in documentation, testing, and similar areas. Any changes must be backward-compatible.
 - **kind/refactor** - For PRs that restructure or remove code without adding new functionality. This label also applies to changes that affect user-facing APIs.
 
+## Review readiness
+
+We use the **ready-for-review** label to signal that a PR is waiting for a (re-)review:
+
+- **Add** `ready-for-review` when you open a PR that is ready for review, or when a PR is ready for re-review (for example, once you have addressed requested changes and re-requested review).
+- The label is **removed automatically** by the [`Ready-for-review label`](../.github/workflows/ready-for-review-label.yml) workflow once the PR is no longer awaiting that review, specifically when any of the following become true:
+  - the PR is closed or merged,
+  - the PR is converted to a draft,
+  - the PR has two or more approvals, or
+  - the PR has two or more change requests.
+
+You only ever need to add the label; removal is fully automated.
+
 ---
 
 # **Issues**