Add agentic workflows for community catalog submissions (#2655)

* Add agentic workflows for community catalog submissions

Add GitHub Agentic Workflows that automatically process community
extension and preset submission issues:

- add-community-extension.md: triggered by extension-submission issues,
  validates the submission, updates extensions/catalog.community.json
  and docs/community/extensions.md, then opens a draft PR
- add-community-preset.md: parallel workflow for preset-submission
  issues, updates presets/catalog.community.json and
  docs/community/presets.md

Both workflows:
- Trigger on opened, edited, or labeled events (maintainers can
  retroactively label pre-existing issues)
- Validate ID format, semver, repo existence, required files, release,
  and submission checklists
- Label issues with validation-passed or validation-failed
- Create draft PRs with Closes #N for maintainer review

Also includes gh-aw scaffolding (.github/aw/, .gitattributes lock file
rule, dependabot ignore for gh-aw-actions).

* Suppress whitespace checks on generated .lock.yml files

These files are auto-generated by gh aw compile and contain trailing
whitespace in the ASCII art header and indented YAML blocks that we
cannot control. Add -whitespace attribute to skip git whitespace
checks on them.
This commit is contained in:
Manfred Riem
2026-05-21 07:13:11 -05:00
committed by GitHub
parent b4b83be51b
commit 0964f113b7
7 changed files with 3755 additions and 10 deletions

14
.github/aw/actions-lock.json vendored Normal file
View File

@@ -0,0 +1,14 @@
{
"entries": {
"actions/github-script@v9.0.0": {
"repo": "actions/github-script",
"version": "v9.0.0",
"sha": "3a2844b7e9c422d3c10d287c895573f7108da1b3"
},
"github/gh-aw-actions/setup@v0.74.8": {
"repo": "github/gh-aw-actions/setup",
"version": "v0.74.8",
"sha": "efa55847f72aadb03490d955263ff911bf758700"
}
}
}

View File

@@ -1,11 +1,12 @@
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
- directory: /
package-ecosystem: pip
schedule:
interval: weekly
- directory: /
ignore:
- dependency-name: "github/gh-aw-actions/**" # Managed by gh aw compile. Version-locked to the gh-aw compiler; do not bump.
package-ecosystem: github-actions
schedule:
interval: weekly
version: 2

1579
.github/workflows/add-community-extension.lock.yml generated vendored Normal file

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,288 @@
---
description: "Process community extension submission issues — validate, add to catalog, and open a PR for maintainer review"
emoji: "🧩"
on:
issues:
types: [opened, edited, labeled]
skip-bots: [github-actions, copilot, dependabot]
tools:
edit:
bash: ["echo", "cat", "head", "tail", "grep", "wc", "sort", "python3", "jq", "date"]
github:
toolsets: [issues, repos]
web-fetch:
permissions:
contents: read
issues: read
checkout:
fetch-depth: 0
safe-outputs:
create-pull-request:
title-prefix: "[extension] "
labels: [extension-submission, automated]
draft: true
max: 1
protected-files:
policy: blocked
exclude:
- README.md
- CHANGELOG.md
add-comment:
max: 2
add-labels:
allowed: [extension-submission, validation-passed, validation-failed, needs-info]
max: 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 triggers on issue events. **Only process the issue if ALL of these
conditions are met:**
1. The issue has the `extension-submission` label
2. The issue title starts with `[Extension]:`
If the issue does not meet these conditions, add a brief comment explaining that
this workflow only processes extension submission issues, then stop.
## 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:
```json
{
"<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"`:
```json
"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:
```bash
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`

1579
.github/workflows/add-community-preset.lock.yml generated vendored Normal file

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,282 @@
---
description: "Process community preset submission issues — validate, add to catalog, and open a PR for maintainer review"
emoji: "🎨"
on:
issues:
types: [opened, edited, labeled]
skip-bots: [github-actions, copilot, dependabot]
tools:
edit:
bash: ["echo", "cat", "head", "tail", "grep", "wc", "sort", "python3", "jq", "date"]
github:
toolsets: [issues, repos]
web-fetch:
permissions:
contents: read
issues: read
checkout:
fetch-depth: 0
safe-outputs:
create-pull-request:
title-prefix: "[preset] "
labels: [preset-submission, automated]
draft: true
max: 1
protected-files:
policy: blocked
exclude:
- README.md
- CHANGELOG.md
add-comment:
max: 2
add-labels:
allowed: [preset-submission, validation-passed, validation-failed, needs-info]
max: 3
---
# Add Community Preset from Issue Submission
You are a catalog maintenance agent for the Spec Kit project. Your job is to
process community preset submission issues and create pull requests that add
or update entries in the community preset catalog.
## Triggering Conditions
This workflow triggers on issue events. **Only process the issue if ALL of these
conditions are met:**
1. The issue has the `preset-submission` label
2. The issue title starts with `[Preset]:`
If the issue does not meet these conditions, add a brief comment explaining that
this workflow only processes preset submission issues, then stop.
## 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 |
|-------|--------------|----------|
| Preset ID | `preset-id` | Yes |
| Preset Name | `preset-name` | Yes |
| Version | `version` | Yes |
| Description | `description` | Yes |
| Author | `author` | Yes |
| Repository URL | `repository` | Yes |
| Download URL | `download-url` | Yes |
| License | `license` | Yes |
| Required Spec Kit Version | `speckit-version` | Yes |
| Required Extensions | `required-extensions` | No |
| Templates Provided | `templates-provided` | Yes |
| Commands Provided | `commands-provided` | Yes |
| Number of Scripts | `scripts-count` | No (default 0) |
| Tags | `tags` | Yes |
The issue body uses GitHub's issue form format. Each field appears under a
heading matching the field label (e.g., `### Preset 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. Preset 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 a `preset.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 `presets/catalog.community.json` for the preset ID.
- **Not found** → this is a **new addition**
- **Found** → this is an **update** — replace the existing entry in-place;
preserve `created_at` from the existing entry
## Step 4 — Update `presets/catalog.community.json`
Edit `presets/catalog.community.json` to add or update the preset entry.
### For a new preset
Insert the entry in **alphabetical order by preset ID** within the
`"presets"` object. Use this structure:
```json
{
"<id>": {
"name": "<name>",
"id": "<id>",
"version": "<version>",
"description": "<description>",
"author": "<author>",
"repository": "<repository>",
"download_url": "<download_url>",
"homepage": "<homepage or repository>",
"documentation": "<documentation or repository README>",
"license": "<license>",
"requires": {
"speckit_version": "<speckit_version>"
},
"provides": {
"templates": <N>,
"commands": <N>
},
"tags": ["<tag1>", "<tag2>"],
"created_at": "<today>T00:00:00Z",
"updated_at": "<today>T00:00:00Z"
}
}
```
If the preset has required extensions, add an `"extensions"` array inside
`"requires"`:
```json
"requires": {
"speckit_version": "<speckit_version>",
"extensions": ["<extension-id>"]
}
```
If the preset provides scripts, add `"scripts": <N>` inside `"provides"`.
### For an update
Replace only the changed fields (typically `version`, `download_url`,
`description`, `provides`, `requires`, `tags`, `updated_at`). **Preserve**
`created_at` from the existing entry.
### Counting templates and commands
Parse the "Templates Provided" and "Commands Provided" issue fields:
- Count the number of list items (lines starting with `-`)
- If the field says "None", the count is 0
### 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:
```bash
python3 -c "import json; json.load(open('presets/catalog.community.json')); print('Valid JSON')"
```
If validation fails, fix the JSON and re-validate before continuing.
## Step 5 — Update `docs/community/presets.md`
Edit `docs/community/presets.md` to add or update a row in the Community
Presets table.
### For a new preset
Insert a new row in **alphabetical order by preset name**:
```
| <Name> | <Description> | <N> templates, <N> commands | <Requires> | [<repo-name>](<repository-url>) |
```
For the Requires column:
- Use `—` if no extensions are required
- List required extension names if any (e.g., `AIDE extension`)
If the preset provides scripts, include them: `<N> templates, <N> commands, <N> scripts`
### 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 preset:** `add-<preset-id>-preset`
- **Update:** `update-<preset-id>-preset`
### Commit message
For a new preset:
```
Add <Name> preset to community catalog
Add <id> preset submitted by @<issue-author> to:
- presets/catalog.community.json (alphabetical order)
- docs/community/presets.md community presets table
Closes #<issue-number>
```
For an update:
```
Update <Name> preset to v<version>
Update <id> preset submitted by @<issue-author>:
- presets/catalog.community.json (version, download_url, etc.)
- docs/community/presets.md community presets 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
- **Preserve `created_at` on updates** — keep the original value; only update
`updated_at`
- **Do not modify any other files** — only `presets/catalog.community.json`
and `docs/community/presets.md`