Knowing when a catalog extension stops working with a new spec-kit release

[alfredoperez]

A user of my extension (SpecKit Companion) suggested that every extension in the catalog should name someone, a person or a bot, responsible for keeping it working with new spec-kit versions. I think the idea is right, and I looked at how big the gap is in the v1.2.5 community catalog:

• 186 extensions are listed.
• 58 still declare >=0.1.0 as their minimum spec-kit version, which tells a user nothing now that spec-kit is at 1.2.
• About 70 haven't been updated since April.
• The publishing guide says review checks the catalog entry, not the extension itself, so nothing notices when a new spec-kit release breaks one.

A named maintainer helps, but only if something tells them when their extension breaks. Two small ideas:

1. A "tested with" field in each catalog entry: the last spec-kit version the author checked it against. The catalog page or specify extension search could mark entries that are several releases behind.
2. An install check on each release: when spec-kit ships, a job tries specify extension add for each catalog entry in a fresh project and records which ones fail. The maintainer named in the entry gets the result.

Would either fit the catalog process? Happy to help with the first one, starting with my own entry.

Context: alfredoperez/speckit-companion#924

AI disclosure: drafted with Claude Code (Claude Opus 5.5, default settings) from the v1.2.5 catalog file; I checked the numbers before posting.

[mnriem]

Thanks for sharing these ideas. The catalog already includes an author and a link to each extension’s repository, where users can raise questions or report issues, so an additional maintainer field isn’t needed. The community catalog helps users discover extensions; establishing compatibility and keeping extensions working with new Spec Kit releases are the responsibility of each extension’s maintainers, rather than the Spec Kit project.

AI disclosure: Drafted with GitHub Copilot (GPT-6.1 Sol), interactively at the contributor’s request.

[alfredoperez]

Thanks for the answer, that makes sense. I'll keep compatibility on our side for SpecKit Companion. Closing this one.