
add-community-extension
Add a community extension to the Spec Kit catalog from a GitHub issue submission. USE FOR: processing extension submission issues, validating catalog entries, updating catalog.community.json and docs/community/extensions.md, creating PRs. DO NOT USE FOR: creating new extensions from scratch, or first-party extension work.
- Installs
- 530
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/github/spec-kit --skill add-community-extension- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads add-community-extension automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Add Community Extension
Process an extension submission issue and add or update it in the community catalog.
When to Use
- A new
[Extension]submission issue is filed - An existing extension submits an update issue (new version, changed metadata)
- You need to add or update a community extension in
extensions/catalog.community.jsonanddocs/community/extensions.md
Procedure
1. Fetch the submission issue
Read the GitHub issue to extract all metadata:
- Extension ID, name, version, description, author
- Repository URL, download URL, homepage, documentation, changelog
- License, required spec-kit version, optional tool dependencies
- Number of commands and hooks
- Tags
2. Validate against publishing rules
Check all of the following (per extensions/EXTENSION-PUBLISHING-GUIDE.md):
| Check | How |
|---|---|
| Repository exists and is public | Fetch the repository URL |
extension.yml manifest present | Confirm in repo file listing |
| README.md present | Confirm in repo file listing |
| LICENSE file present | Confirm in repo file listing |
| GitHub release exists matching version | Check releases on the repo page |
| Download URL is accessible | Verify it follows archive/refs/tags/vX.Y.Z.zip pattern and release exists |
| Extension ID is lowercase-with-hyphens only | Regex: ^[a-z][a-z0-9-]*$ |
| Version follows semver | Format: X.Y.Z |
| Submission checklists are all checked | Confirm in issue body |
3. Determine if this is an add or update
Search extensions/catalog.community.json for the extension ID.
- Not found → this is a new addition. Proceed to step 4.
- Found → this is an update. Proceed to step 4 but replace the existing entry in-place instead of inserting.
4. Add or update extensions/catalog.community.json
New extension: Insert the entry in alphabetical order by extension ID.
Update: Replace the existing entry in-place. Update only the fields that changed (typically version, download_url, description, provides, requires, tags, updated_at). Preserve created_at and downloads/stars from the existing entry.
Use the existing entries as the format template. Required fields:
{
"<id>": {
"name": "<name>",
"id": "<id>",
"description": "<description>",
"author": "<author>",
"version": "<version>",
"download_url": "<download_url>",
"repository": "<repository>",
"homepage": "<homepage>",
"documentation": "<documentation>",
"changelog": "<changelog>",
"license": "<license>",
"category": "<category>",
"effect": "<effect>",
"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"
}
}
Category — free-form string; common values: docs, code, process, integration, visibility
Effect — one of: read-only, read-write
If the extension has optional tool dependencies, add a "tools" array inside "requires":
"tools": [{ "name": "<tool>", "required": false }]
Also update the top-level "updated_at" timestamp in the catalog.
After editing, validate the JSON by running:
python3 -c "import json; json.load(open('extensions/catalog.community.json')); print('Valid JSON')"
5. Add or update docs/community/extensions.md community extensions table
New extension: Insert a new row into the # Community Extensions table in alphabetical order by extension name.
Update: Find the existing row and update the description or other changed fields in-place.
Determine the category and effect from the extension's behavior:
| <Name> | <Description> | `<category>` | <Effect> | [<repo-name>](<repository-url>) |
Category — free-form; common values: docs, code, process, integration, visibility
Effect — write canonical values read-only or read-write in extension.yml and catalog.community.json; use Read-only/Read+Write only for the docs table display
6. Commit, push, and open PR
Use add- for new extensions, update- for updates:
# New extension
git checkout -b add-<extension-id>-extension
# Update
git checkout -b update-<extension-id>-extension
git add extensions/catalog.community.json docs/community/extensions.md
# New extension
git commit -m "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>"
# Update
git commit -m "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>"
git push origin <branch-name>
Then create a PR to upstream (github/spec-kit) with:
- Title:
Add <Name> extension to community catalog(orUpdate <Name> extension to v<version>) - Body: Include validation summary,
Closes #<issue-number>, andcc @<issue-author> - Head:
<fork-owner>:<branch-name> - Base:
main
Common Pitfalls
- Alphabetical order matters — entries must be sorted by ID in the JSON and by name in the docs table.
- Don't forget the catalog
updated_at— the top-level timestamp incatalog.community.jsonmust be refreshed. - Validate JSON after editing — a trailing comma or missing brace will break the catalog.
- Use
ClosesnotFixes—Closes #Nis 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.
- Preserve
created_aton updates — keep the originalcreated_atvalue; only changeupdated_at. - Preserve
downloadsandstarson updates — these reflect usage metrics and must not be reset.
FAQ
What does the add-community-extension skill do?
Add a community extension to the Spec Kit catalog from a GitHub issue submission. USE FOR: processing extension submission issues, validating catalog entries, updating catalog.community.json and docs/community/extensions.md, creating PRs. DO NOT USE FOR: creating new extensions from scratch, or first-party extension work.
How do I install add-community-extension?
Run npx skills add https://github.com/github/spec-kit --skill add-community-extension in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/add-community-extension/ (personal) or .claude/skills/add-community-extension/ (project).
Which AI agents can use add-community-extension?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is add-community-extension safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains add-community-extension?
It is published by github in github/spec-kit, and it is an official skill from the maker of the technology it covers. It has 530 recorded installs.
More from github/spec-kit
code-review
github/spec-kit
Reviews Spec Kit code changes for consistency with applicable design documents, positive and negative test coverage, regression evidence for bug fixes, and consistent repository terminology. Use when reviewing a diff or pull request. Do not use for implementing changes or posting GitHub review actions.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.