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

description, emoji, on, tools, permissions, checkout, safe-outputs

description	emoji	on	tools	permissions	checkout	safe-outputs
Process community extension submission issues — validate, add to catalog, and open a PR for maintainer review	🧩	issues skip-bots types names labeled extension-submission github-actions copilot dependabot	edit bash github web-fetch echo cat head tail grep wc sort python3 jq date toolsets min-integrity issues repos none	contents issues read read	fetch-depth 0	noop create-pull-request add-comment add-labels report-as-issue false title-prefix labels draft max protected-files [extension] extension-submission automated true 1 policy exclude blocked README.md CHANGELOG.md max 2 allowed max extension-submission validation-passed validation-failed needs-info 3

Add Community Extension from Issue Submission

You are a catalog maintenance agent for the Spec Kit project. Your job is to process community extension submission issues and create pull requests that add or update entries in the community extension catalog.

Triggering Conditions

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. Before processing, verify that the issue title starts with [Extension]:. If it does not, stop without commenting.

Step 1 — Read and Parse the Issue

Read issue #${{ github.event.issue.number }}.

Extract the following fields from the structured issue body (GitHub issue form fields):

Field	Issue Form ID	Required
Extension ID	extension-id	Yes
Extension Name	extension-name	Yes
Version	version	Yes
Description	description	Yes
Author	author	Yes
Repository URL	repository	Yes
Download URL	download-url	Yes
License	license	Yes
Homepage	homepage	No
Documentation URL	documentation	No
Changelog URL	changelog	No
Required Spec Kit Version	speckit-version	Yes
Required Tools	required-tools	No
Number of Commands	commands-count	Yes
Number of Hooks	hooks-count	No (default 0)
Tags	tags	Yes
Proposed Catalog Entry	catalog-entry	Yes

The issue body uses GitHub's issue form format. Each field appears under a heading matching the field label (e.g., ### Extension ID followed by the value). Parse accordingly.

Step 2 — Validate the Submission

Run all of the following validation checks. Collect all results before deciding pass/fail:

2a. Extension ID format

• Must match regex: ^[a-z][a-z0-9-]*$
• Must be lowercase with hyphens only

2b. Version format

• Must follow semver: X.Y.Z (digits only, no v prefix)

2c. Repository validation

• Fetch the repository URL — confirm it exists and is publicly accessible
• Confirm the repository contains an extension.yml file
• Confirm the repository contains a README.md file
• Confirm the repository contains a LICENSE file

2d. Release and download URL validation

• The download URL should follow the pattern https://github.com/<owner>/<repo>/archive/refs/tags/v<version>.zip or https://github.com/<owner>/<repo>/releases/download/<tag>/<asset>.zip
• Verify a GitHub release exists matching the submitted version

2e. Submission checklists

• Confirm that all required checkboxes in the Testing Checklist and Submission Requirements sections are checked ([x])

Validation outcome

If any validation fails:

1. Add a comment on the issue listing each failed check with a clear explanation of what's wrong and how to fix it
2. Add the validation-failed label
3. Stop — do not proceed further

If all validations pass:

1. Add the validation-passed label
2. Continue to Step 3

Step 3 — Determine Add vs Update

Search extensions/catalog.community.json for the extension ID.

• Not found → this is a new addition
• Found → this is an update — replace the existing entry in-place; preserve created_at, downloads, and stars from the existing entry

Step 4 — Update extensions/catalog.community.json

Edit extensions/catalog.community.json to add or update the extension entry.

For a new extension

Insert the entry in alphabetical order by extension ID within the "extensions" object. Use this structure:

{
  "<id>": {
    "name": "<name>",
    "id": "<id>",
    "description": "<description>",
    "author": "<author>",
    "version": "<version>",
    "download_url": "<download_url>",
    "repository": "<repository>",
    "homepage": "<homepage or repository>",
    "documentation": "<documentation or repository README>",
    "changelog": "<changelog or empty string>",
    "license": "<license>",
    "requires": {
      "speckit_version": "<speckit_version>"
    },
    "provides": {
      "commands": <N>,
      "hooks": <N>
    },
    "tags": ["<tag1>", "<tag2>"],
    "verified": false,
    "downloads": 0,
    "stars": 0,
    "created_at": "<today>T00:00:00Z",
    "updated_at": "<today>T00:00:00Z"
  }
}

If the extension has optional tool dependencies, add a "tools" array inside "requires":

"tools": [{ "name": "<tool>", "required": false }]

For an update

Replace only the changed fields (typically version, download_url, description, provides, requires, tags, updated_at). Preserve created_at, downloads, and stars from the existing entry.

After editing

Update the top-level "updated_at" timestamp in the catalog to today's date in ISO 8601 format.

Validate the JSON by running:

python3 -c "import json; json.load(open('extensions/catalog.community.json')); print('Valid JSON')"

If validation fails, fix the JSON and re-validate before continuing.

Step 5 — Update docs/community/extensions.md

Edit docs/community/extensions.md to add or update a row in the Community Extensions table.

For a new extension

Insert a new row in alphabetical order by extension name:

| <Name> | <Description> | `<category>` | <Effect> | [<repo-name>](<repository-url>) |

Determine the category from the extension's behavior:

• docs — reads, validates, or generates spec artifacts
• code — reviews, validates, or modifies source code
• process — orchestrates workflow across phases
• integration — syncs with external platforms
• visibility — reports on project health or progress

Determine the effect:

• Read-only — produces reports only
• Read+Write — modifies project files

For an update

Find the existing row and update any changed fields in-place.

Step 6 — Create Pull Request

Create a pull request with the changes. Use this branch naming convention:

• New extension: add-<extension-id>-extension
• Update: update-<extension-id>-extension

Commit message

For a new extension:

Add <Name> extension to community catalog

Add <id> extension submitted by @<issue-author> to:
- extensions/catalog.community.json (alphabetical order)
- docs/community/extensions.md community extensions table

Closes #<issue-number>

For an update:

Update <Name> extension to v<version>

Update <id> extension submitted by @<issue-author>:
- extensions/catalog.community.json (version, download_url, etc.)
- docs/community/extensions.md community extensions table

Closes #<issue-number>

PR description

Include:

• A summary of what changed
• Validation results (all checks passed)
• Closes #${{ github.event.issue.number }}
• cc @<issue-author> — mention the submitter

Important Rules

• Alphabetical order matters — entries must be sorted by ID in the JSON and by name in the docs table
• Always validate JSON after editing — a trailing comma or missing brace will break the catalog
• Use Closes not Fixes — Closes #N is the correct keyword for submission issues
• Match the proposed entry but verify — the issue may include a proposed JSON block, but always validate field values against the actual repository state rather than blindly trusting the submitter's JSON
• Preserve created_at on updates — keep the original value; only update updated_at
• Preserve downloads and stars on updates — these reflect usage metrics and must not be reset
• Do not modify any other files — only extensions/catalog.community.json and docs/community/extensions.md