본문으로 건너뛰기
cccskills
무료GitHub에 공개

add-community-extension

Process GitHub issues submitted for Spec Kit community extensions. Validate release details and required files, add or update the catalog and documentation table, and prepare a pull request with a validation summary.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

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.

연동 도구GitHub
설치 방법 보기

이럴 때 유용합니다

  • Adding a newly submitted community extension
  • Updating an extension version or metadata
  • Checking submissions against publishing rules
  • Keeping the catalog and documentation table aligned

포함된 파일(1)

  • SKILL.md6.5 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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.json and docs/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):

CheckHow
Repository exists and is publicFetch the repository URL
extension.yml manifest presentConfirm in repo file listing
README.md presentConfirm in repo file listing
LICENSE file presentConfirm in repo file listing
GitHub release exists matching versionCheck releases on the repo page
Download URL is accessibleVerify it follows archive/refs/tags/vX.Y.Z.zip pattern and release exists
Extension ID is lowercase-with-hyphens onlyRegex: ^[a-z][a-z0-9-]*$
Version follows semverFormat: X.Y.Z
Submission checklists are all checkedConfirm 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 (or Update <Name> extension to v<version>)
  • Body: Include validation summary, Closes #<issue-number>, and cc @<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 in catalog.community.json must be refreshed.
  • 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.
  • Preserve created_at on updates — keep the original created_at value; only change updated_at.
  • Preserve downloads and stars on updates — these reflect usage metrics and must not be reset.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Review Spec Kit code changes against relevant design documents, tests for expected and unwanted behavior, evidence that bug fixes prevent recurrence, and repository terminology. Findings identify the document sections behind design mismatches.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reviewing a Spec Kit pull request
  • Checking test coverage for expected and unwanted behavior
  • Checking regression evidence for a bug fix
github/spec-kit14.2만2026년 10월 17일 업데이트

github의 스킬 모두 보기

이 스킬의 문제 신고