Revert community submission intake and outcome reporting changes (#4831)

Create space for additional hosted validation before proceeding with or reintroducing the changes from #4829.

Assisted-by: GitHub Copilot App (model: GPT-5.6 Sol, autonomous)

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: KSchlobohm

.github/workflows/add-community-bundle.lock.yml

@@ -8,9 +8,6 @@ on:
     names: [bundle-submission]
   skip-bots: [github-actions, copilot, dependabot]
 
-imports:
-  - shared/catalog-submission.md
-
 engine:
   id: copilot
   args:
@@ -111,9 +108,8 @@ not turn environment blockers into submission failures.
 ## Triggering Conditions
 
 This workflow is triggered by an `issues: labeled` event and is gated to the
-`bundle-submission` label. Use the shared submission intake and outcome
-reporting instructions to determine whether the issue is a bundle submission.
-Do not require an exact title prefix or stop without an issue outcome comment.
+`bundle-submission` label. Before processing, verify that the issue title starts
+with `[Bundle]:`. If it does not, stop without commenting.
 
 ## Step 1 - Read and Parse the Issue
 

.github/workflows/add-community-bundle.md

@@ -8,9 +8,6 @@ on:
     names: [extension-submission]
   skip-bots: [github-actions, copilot, dependabot]
 
-imports:
-  - shared/catalog-submission.md
-
 engine:
   id: copilot
   args:
@@ -92,9 +89,8 @@ not turn environment blockers into submission failures.
 This workflow is triggered by any `issues: labeled` event, but a job-level
 condition gates the agent run so it only proceeds when the label that was just
 added is `extension-submission`. By the time you run, that condition has already
-passed. Use the shared submission intake and outcome reporting instructions to
-determine whether the issue is an extension submission. Do not require an exact
-title prefix or stop without an issue outcome comment.
+passed. Before processing, verify that the issue title starts with `[Extension]:`.
+If it does not, stop without commenting.
 
 ## Step 1 — Read and Parse the Issue
 

.github/workflows/add-community-extension.lock.yml

@@ -8,9 +8,6 @@ on:
     names: [preset-submission]
   skip-bots: [github-actions, copilot, dependabot]
 
-imports:
-  - shared/catalog-submission.md
-
 engine:
   id: copilot
   args:
@@ -102,9 +99,8 @@ not turn environment blockers into submission failures.
 This workflow is triggered by any `issues: labeled` event, but a job-level
 condition gates the agent run so it only proceeds when the label that was just
 added is `preset-submission`. By the time you run, that condition has already
-passed. Use the shared submission intake and outcome reporting instructions to
-determine whether the issue is a preset submission. Do not require an exact
-title prefix or stop without an issue outcome comment.
+passed. Before processing, verify that the issue title starts with `[Preset]:`.
+If it does not, stop without commenting.
 
 ## Step 1 — Read and Parse the Issue
 

.github/workflows/add-community-extension.md

@@ -224,15 +224,6 @@ and [bundles](https://github.com/github/spec-kit/blob/main/.github/workflows/add
 validate submission metadata and propose catalog changes in draft PRs for
 maintainer review.
 
-Submission labels start these workflows. The agent uses the title and
-type-specific issue-form fields together, rather than requiring exact title
-punctuation. Wrong-type or unclear submissions receive an explanatory issue
-comment; maintainers decide how to relabel or clarify them. Every processing
-path reports an outcome and workflow run link. A separate reporting job adds
-a fallback status if the run ends without an outcome comment, distinguishing
-a published draft PR from incomplete processing. Agent or safe-output failures
-still receive a status comment if an earlier agent comment was already posted.
-
 Catalog discovery does not audit or endorse community code; users must
 review third-party components before use.