diff --git a/.github/ISSUE_TEMPLATE/bundle_submission.yml b/.github/ISSUE_TEMPLATE/bundle_submission.yml
index c2b928f3a..82bd0ef9e 100644
--- a/.github/ISSUE_TEMPLATE/bundle_submission.yml
+++ b/.github/ISSUE_TEMPLATE/bundle_submission.yml
@@ -16,6 +16,8 @@ body:
         - If you host a bundle catalog, test catalog installation with `specify bundle catalog add <catalog-url> --id <catalog-id> --policy install-allowed` and `specify bundle install <bundle-id>`
         - If your bundle depends on components from non-default catalogs, document those catalog URLs and test installation from a clean project
 
+        **After submitting:** a maintainer applies the `bundle-submission` label during issue triage, which starts the automated catalog validation. You don't need to apply any label or ask for one.
+
   - type: input
     id: bundle-id
     attributes:
diff --git a/.github/ISSUE_TEMPLATE/extension_submission.yml b/.github/ISSUE_TEMPLATE/extension_submission.yml
index 62508dd56..eae85a434 100644
--- a/.github/ISSUE_TEMPLATE/extension_submission.yml
+++ b/.github/ISSUE_TEMPLATE/extension_submission.yml
@@ -14,6 +14,8 @@ body:
         - Create a GitHub release with a version tag (e.g., v1.0.0)
         - Test installation: `specify extension add <extension-name> --from <your-release-url>`
 
+        **After submitting:** a maintainer applies the `extension-submission` label during issue triage, which starts the automated catalog validation. You don't need to apply any label or ask for one.
+
   - type: input
     id: extension-id
     attributes:
diff --git a/.github/ISSUE_TEMPLATE/preset_submission.yml b/.github/ISSUE_TEMPLATE/preset_submission.yml
index 45c1f8173..bb41d5fe1 100644
--- a/.github/ISSUE_TEMPLATE/preset_submission.yml
+++ b/.github/ISSUE_TEMPLATE/preset_submission.yml
@@ -14,6 +14,8 @@ body:
         - Create a GitHub release with a version tag (e.g., v1.0.0)
         - Test installation from the release archive: `specify preset add --from <download-url>`
 
+        **After submitting:** a maintainer applies the `preset-submission` label during issue triage, which starts the automated catalog validation. You don't need to apply any label or ask for one.
+
   - type: input
     id: preset-id
     attributes:
diff --git a/extensions/EXTENSION-PUBLISHING-GUIDE.md b/extensions/EXTENSION-PUBLISHING-GUIDE.md
index 13fd08b79..f0eff5417 100644
--- a/extensions/EXTENSION-PUBLISHING-GUIDE.md
+++ b/extensions/EXTENSION-PUBLISHING-GUIDE.md
@@ -151,7 +151,7 @@ To submit your extension to the community catalog, file a new issue using the **
 
 ### What Happens After You Submit
 
-1. Your issue is automatically labeled and assigned to a maintainer for review
+1. A maintainer reviews the issue during issue triage and applies the `extension-submission` label, which starts the automated catalog validation. On this public repository, contributors cannot apply that label themselves, so there is nothing to label or re-request — the issue simply waits in triage.
 2. A maintainer verifies that the catalog entry is complete and correctly formatted
 3. Once approved, the maintainer adds your extension to `extensions/catalog.community.json` and the Community Extensions table in the README
 4. Your extension becomes discoverable via `specify extension search`
diff --git a/presets/PUBLISHING.md b/presets/PUBLISHING.md
index 24abffda5..f71c1f45d 100644
--- a/presets/PUBLISHING.md
+++ b/presets/PUBLISHING.md
@@ -300,6 +300,12 @@ git push origin add-your-preset
 
 ## Verification Process
 
+> **How submissions get picked up:** the automated catalog-validation workflow only runs
+> once the `preset-submission` label is on the issue. On this public repository, contributors
+> cannot apply that label themselves — a maintainer applies it during issue triage. Until then
+> the issue simply waits in triage; there is no action required from you, and there is no need to
+> re-request the label in a comment.
+
 After submission, maintainers will review:
 
 1. **Manifest validation** — valid `preset.yml`, all files exist