docs: clarify maintainer applies submission label during triage (#4041)

Community extension, preset, and bundle submissions are validated by
label-triggered agentic workflows that only run once the corresponding
`*-submission` label is applied. On this public repo contributors cannot
apply that label themselves, so a maintainer applies it during issue
triage. Document this in the three submission issue templates, the preset
publishing guide, and correct the extension guide's inaccurate claim that
issues are "automatically labeled and assigned".

Assisted-by: GitHub Copilot (model: Claude Opus 4.8, autonomous)

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 3b6f6854-9be6-4b67-b5b9-34b19ededcb8

.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:

.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:

.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:

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`

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