submit-catalog-update

Solid

File the spec-kit community-catalog update for the `companion` extension as an Extension Submission ISSUE on github/spec-kit (never a PR — direct catalog PRs are rejected). Renders the issue body from the LIVE upstream issue-form template so our headings can't drift from theirs. Minor and major releases only. Use when the user says "/submit-catalog-update", "update the catalog", "file the catalog issue", "the catalog is stale", or right after /publish-speckit-ext cuts a minor or major spec-kit-extension release.

Data & Documents 90 stars 23 forks Updated 4 days ago MIT

Install

View on GitHub

Quality Score: 85/100

Stars 20%
65
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Submit a community-catalog update The catalog entry for `companion` is version-pinned, so a release only reaches catalog users once the entry is bumped. This files that bump. Deliberately no `Edit`/`Write`: this skill writes to a third-party repository and must not be able to mutate ours. ## Hard-won rules (do not skip) 1. **Never open a PR against `extensions/catalog.community.json`.** github/spec-kit#3937 was closed unmerged — *"Updates to extensions must use the extension submission issue template."* The publishing guide is explicit: *"Do not open a pull request directly to edit `extensions/catalog.community.json`."* Both first listings and version updates go through the **[Extension Submission] issue**. If you find yourself typing `gh pr create` against `github/spec-kit`, you are in the wrong workflow. 2. **Never hardcode the `###` headings.** GitHub serializes an issue form as `### <label>` / blank / value, and maintainers' validation parses that. `render_submission.py` fetches the live `.github/ISSUE_TEMPLATE/extension_submission.yml` and renders from its labels — including the `(optional)` suffixes. If it cannot fetch the template it aborts; it never falls back to a remembered shape, because that fallback is the failure this skill exists to prevent. 3. **The download URL is the version-pinned asset** — `…/releases/download/speckit-ext-v$V/companion-$V.zip`. Never `companion-latest/companion.zip`: the catalog requires the declared version to equal the downloaded b...

Details

Author
alfredoperez
Repository
alfredoperez/speckit-companion
Created
9 months ago
Last Updated
4 days ago
Language
HTML
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

spec-update

Use when behaviour is about to change and the spec needs to say how it will work afterwards, before the code moves - "we're changing how cancellations work, spec it first", "this branch changes X, make the spec match". On a branch the spec is the target and the git diff is the delta; updates every affected spec, not only the one that came to mind.

4 Updated 1 weeks ago
repository-standards
AI & Automation Listed

skill-agent-catalog-apply

Wires up the MkDocs skill-and-agent catalog in the current repository per the canonical-language file under spec/claude/skill-agent-catalog/. Audits the MkDocs config against the spec, scaffolds or patches the catalog generator surface (the `on_pre_build` hook by default, or a standalone pre-build step; gen-files is forbidden under mkdocs-static-i18n folder mode) plus literate-nav, writes the generator module that walks every configured plugin source root, and verifies a docs build produces Skills and Agents sections. Invoke when the user asks to "apply the skill-agent-catalog spec", "wire up the catalog generator", "scaffold the skills/agents navigation", or "add another plugin source root". Also handles equivalent German-language requests and checking whether a wired catalog is still in sync. Don't use for authoring individual skills/agents (use `skill-management`) or for general docs scaffolding (use `project-structure-apply`). Supports resume on re-invocation per `spec/claude/resumable-work/`.

0 Updated yesterday
nolte
Code & Development Listed

publish-chrome-extension

Republish a new release of an existing Chrome extension to the Chrome Web Store: downloads the release zip from GitHub, checks what changed since the version the store already holds, uploads the zip via the Web Store API, and submits it for review. TRIGGER when: the user wants to publish, republish, or upload a new extension version to the Chrome Web Store, typically right after /release. DO NOT TRIGGER when: creating a brand-new store listing, editing store listing content (description, screenshots), or building/tagging a release (use /release for that).

1 Updated today
AnotherSava