diff --git a/.github/workflows/ready-for-review-label.yml b/.github/workflows/ready-for-review-label.yml
new file mode 100644
index 00000000..e63389aa
--- /dev/null
+++ b/.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 }}
diff --git a/docs/github-labels.md b/docs/github-labels.md
index 041d37c8..4509e157 100644
--- a/docs/github-labels.md
+++ b/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**