diff --git a/.github/workflows/pr-review.yml b/.github/workflows/pr-review.yml
index 46adc44..f94f051 100644
--- a/.github/workflows/pr-review.yml
+++ b/.github/workflows/pr-review.yml
@@ -149,9 +149,11 @@ jobs:
 
   labels-bootstrap:
     name: 'Bootstrap review labels'
+    # Runs on every trigger event, NOT gated on should_run: on a clean
+    # installation the `Ready` label does not exist yet, and gating this job
+    # on `Ready` being applied would make the bootstrap unreachable
+    # (chicken-and-egg). The job is idempotent and costs ~4s.
     needs: scope
-    # Only bootstrap when we're actually going to review — no work otherwise.
-    if: needs.scope.outputs.should_run == 'true'
     runs-on: ubuntu-latest
     permissions:
       issues: write
diff --git a/AGENTS.md b/AGENTS.md
index 2dae9d8..75f59db 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -309,7 +309,7 @@ The implementation lives in `dailybot_cli/config.py` (`get_active_env_profile`,
 
 > **TL;DR — every PR releases by default. The only way to suppress it is to type `[skip release]` into the squash-commit body in the GitHub merge dialog yourself, on a PR that meets one of the accepted use cases below.**
 
-There is **one** narrow situation in which auto-releasing the CLI is actively harmful: syncing the in-repo vendored copy of the Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published `DailybotHQ/agent-skill` release. The skill pack pins a `dailybot-cli >= X.Y.Z` floor, so if the dogfood-sync PR triggered a release, the CLI would advance past that floor, the freshly synced skill pack would go stale instantly, and we would enter an infinite loop:
+There are **two** narrow situations in which auto-releasing the CLI is wrong (both enumerated in rule 3 below). The motivating one — where a release is actively harmful, not just empty — is syncing the in-repo vendored copy of the Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published `DailybotHQ/agent-skill` release. The skill pack pins a `dailybot-cli >= X.Y.Z` floor, so if the dogfood-sync PR triggered a release, the CLI would advance past that floor, the freshly synced skill pack would go stale instantly, and we would enter an infinite loop:
 
 ```
 sync skill pack → merge → CLI auto-bumps → skill pack now references old CLI
diff --git a/docs/RELEASE_AND_DISTRIBUTION.md b/docs/RELEASE_AND_DISTRIBUTION.md
index cbfdfbe..c647d48 100644
--- a/docs/RELEASE_AND_DISTRIBUTION.md
+++ b/docs/RELEASE_AND_DISTRIBUTION.md
@@ -156,12 +156,15 @@ If you need a release for commits that don't qualify (e.g. an emergency `chore`-
 
 #### When (and only when) to use it
 
-There is **one** accepted use case: a PR whose entire diff is the synchronisation of the in-repo Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published [`DailybotHQ/agent-skill`](https://github.com/DailybotHQ/agent-skill) release (plus the minimal catalog / `AGENTS.md` updates that reference it). Without the marker, that PR would auto-bump the CLI, which in turn would push the skill pack out of sync with the CLI version it just pinned, creating an infinite sync→bump→resync loop. See [AGENTS.md Rule 15.a](../AGENTS.md#15a-opt-in-release-skip--skip-release-marker) for the full rationale.
+There are **two** accepted use cases (mirroring [AGENTS.md Rule 15.a](../AGENTS.md#15a-opt-in-release-skip--skip-release-marker)):
+
+1. **Dailybot skill-pack dogfood sync** — a PR whose entire diff is the synchronisation of the in-repo Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published [`DailybotHQ/agent-skill`](https://github.com/DailybotHQ/agent-skill) release (plus the minimal catalog / `AGENTS.md` updates that reference it). Without the marker, that PR would auto-bump the CLI, which in turn would push the skill pack out of sync with the CLI version it just pinned, creating an infinite sync→bump→resync loop.
+2. **Vendored agent-tooling sync (maintainer-requested)** — a PR whose entire diff lives in agent/CI tooling that ships nothing to CLI users: vendored skill packs under `.agents/` (DWP, AI Diff Reviewer, …), `.agents/commands/` delegators, `.review/`, `skills-lock.json`, the workflows that wire them, and the docs that reference them. A release would be an empty version bump. This case additionally requires the maintainer to **explicitly request the marker on that specific PR** — there is no standing approval.
 
 Any other use of the marker is a bug. In particular, do **not** apply it to:
 
-- Doc-only PRs (let the PATCH go out — the changelog entry is the record that the doc shipped).
-- CI-only or workflow-only PRs (same reason).
+- Doc-only PRs about the CLI itself (let the PATCH go out — the changelog entry is the record that the doc shipped).
+- CI tweaks to the release/test pipelines (same reason).
 - Dependency-bump PRs (downstream users need to see the bump).
 - Refactors, test-only PRs, comment-only PRs — same.