diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md
index 5d0bfbfbb4..214f262fdc 100644
--- a/COLLABORATOR_GUIDE.md
+++ b/COLLABORATOR_GUIDE.md
@@ -84,7 +84,7 @@ continuous integration tests on the
 ### Involving the CTC
 
 Collaborators may opt to elevate pull requests or issues to the CTC for
-discussion by assigning the ***ctc-agenda*** tag. This should be done
+discussion by assigning the `ctc-review` label. This should be done
 where a pull request:
 
 - has a significant impact on the codebase,
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
index a61d9848b1..86796ef03d 100644
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@@ -42,7 +42,7 @@ modification. See [Consensus Seeking Process](#consensus-seeking-process) below
 for further detail on the consensus model used for governance.
 
 Collaborators may opt to elevate significant or controversial modifications to
-the CTC by assigning the ***ctc-agenda*** tag to a pull request or issue. The
+the CTC by assigning the `ctc-review` label to a pull request or issue. The
 CTC should serve as the final arbiter where required.
 
 For the current list of Collaborators, see the project
@@ -98,7 +98,7 @@ members affiliated with the over-represented employer(s).
 Typical activities of a CTC member include:
 
 * attending the weekly meeting
-* commenting on the weekly CTC meeting issue and issues labeled `ctc-agenda`
+* commenting on the weekly CTC meeting issue and issues labeled `ctc-review`
 * participating in CTC email threads
 * volunteering for tasks that arise from CTC meetings and related discussions
 * other activities (beyond those typical of Collaborators) that facilitate the
@@ -120,10 +120,12 @@ The intention of the agenda is not to approve or review all patches.
 That should happen continuously on GitHub and be handled by the larger
 group of Collaborators.
 
-Any community member or contributor can ask that something be added to
-the next meeting's agenda by logging a GitHub issue. Any Collaborator,
-CTC member, or the moderator can add the item to the agenda by adding
-the ***ctc-agenda*** tag to the issue.
+Any community member or contributor can ask that something be reviewed
+by the CTC by logging a GitHub issue. Any Collaborator, CTC member, or the
+moderator can bring the issue to the CTC's attention by applying the
+`ctc-review` label. If consensus-seeking among CTC members fails for a
+particular issue, it may be added to the CTC meeting agenda by adding the
+`ctc-agenda` label.
 
 Prior to each CTC meeting, the moderator will share the agenda with
 members of the CTC. CTC members can also add items to the agenda at the
diff --git a/doc/onboarding.md b/doc/onboarding.md
index e22c876893..5d0560e176 100644
--- a/doc/onboarding.md
+++ b/doc/onboarding.md
@@ -62,7 +62,8 @@ onboarding session.
   * Labels:
     * There is [a bot](https://github.com/nodejs-github-bot/github-bot) that applies subsystem labels (for example, `doc`, `test`, `assert`, or `buffer`) so that we know what parts of the code base the pull request modifies. It is not perfect, of course. Feel free to apply relevant labels and remove irrelevant labels from pull requests and issues.
     * [**See "Labels"**](./onboarding-extras.md#labels)
-    * Use the `ctc-agenda` if a topic is controversial or isn't coming to a conclusion after an extended time.
+    * Use the `ctc-review` label if a topic is controversial or isn't coming to
+      a conclusion after an extended time.
     * `semver-{minor,major}`:
       * If a change has the remote *chance* of breaking something, use `semver-major`
       * When adding a semver label, add a comment explaining why you're adding it. Do it right away so you don't forget!
@@ -145,7 +146,8 @@ onboarding session.
     the objection is addressed. The options for such a situation include:
       * Engaging those with objections to determine a viable path forward;
       * Altering the pull request to address the objections;
-      * Escalating the discussion to the CTC using the `ctc-agenda` label. This should only be done after other options have been exhausted.
+      * Escalating the discussion to the CTC using the `ctc-review` label. This
+        should only be done after the previous options have been exhausted.
 
   * Wait before merging non-trivial changes.
     * 48 hours during the week and 72 hours on weekends.