1a9e4d1d8d
* feat: add git extension with hooks on all core commands - Create extensions/git/ with 5 commands: initialize, feature, validate, remote, commit - 18 hooks covering before/after for all 9 core commands - Scripts: create-new-feature, initialize-repo, auto-commit, git-common (bash + powershell) - Configurable: branch_numbering, init_commit_message, per-command auto-commit with custom messages - Add hooks to analyze, checklist, clarify, constitution, taskstoissues command templates - Allow hooks-only extensions (no commands required) - Bundle extension in wheel via pyproject.toml force-include - Resolve bundled extensions locally before catalog lookup - Remove planned-but-unimplemented before/after_commit hook refs - Update extension docs (API ref, dev guide, user guide) - 37 new tests covering manifest, install, all scripts (bash+pwsh), config reading, graceful degradation Stage 1: opt-in via 'specify extension add git'. No auto-install, no changes to specify.md or core git init code. Refs: #841, #1382, #1066, #1791, #1191 * fix: set git identity env vars in extension tests for CI runners * fix: address PR review comments - Fix commands property KeyError for hooks-only extensions - Fix has_git() operator precedence in git-common.sh - Align default commit message to '[Spec Kit] Initial commit' across config-template, extension.yml defaults, and both init scripts - Update README to reflect all 5 commands and 18 hooks * fix: address second round of PR review comments - Add type validation for provides.commands (must be list) and hooks (must be dict) in manifest _validate() - Tighten malformed timestamp detection in git-common.sh to catch 7-digit dates without trailing slug (e.g. 2026031-143022) - Pass REPO_ROOT to has_git/Test-HasGit in create-new-feature scripts - Fix initialize command docs: surface errors on git failures, only skip when git is not installed - Fix commit command docs: 'skips with a warning' not 'silently' - Add tests for commands:null and hooks:list rejection * fix: address third round of PR review comments - Remove scripts frontmatter from command files (CommandRegistrar rewrites ../../scripts/ to .specify/scripts/ which points at core scripts, not extension scripts) - Update speckit.git.commit command to derive event name from hook context rather than using a static example - Clarify that hook argument passthrough works via AI agent context (the agent carries conversation state including user's original feature description) * fix: address fourth round of PR review comments - Validate extension_id against ^[a-z0-9-]+$ in _locate_bundled_extension to prevent path traversal (security fix) - Move defaults under config.defaults in extension.yml to match ConfigManager._get_extension_defaults() schema - Ship git-config.yml in extension directory so it's copied during install (provides.config template isn't materialized by ExtensionManager) - Condition handling in hook templates: intentionally matches existing pattern from specify/plan/tasks/implement templates (not a new issue) * fix: add --allow-empty to git commit in initialize-repo scripts Ensures git init succeeds even on empty repos where nothing has been staged yet. * fix: resolve display names to bundled extensions before catalog download When 'specify extension add "Git Branching Workflow"' is used with a display name instead of the ID, the catalog resolver now runs first to map the name to an ID, then checks bundled extensions again with the resolved ID before falling back to network download. Also noted: EXECUTE_COMMAND_INVOCATION and condition handling match the existing pattern in specify/plan/tasks/implement templates (pre-existing, not introduced by this PR). * fix: handle before_/after_ prefixes in auto-commit message derivation - Strip both before_ and after_ prefixes when deriving command name (fixes misleading 'Auto-commit after before_plan' messages) - Include phase (before/after) in default commit messages - Clarify README config example is an override, not default behavior * fix: use portable grep -qw for word boundary in create-new-feature.sh BSD grep (macOS) doesn't support \b as a word boundary. Replace with grep -qw which is POSIX-portable. * fix: validate hook values, numeric --number, and PS warning routing - Validate each hook value is a dict with a 'command' field during manifest _validate() (prevents crash at install time) - Validate --number is a non-negative integer in bash create-new-feature (clear error instead of cryptic shell arithmetic failure) - Route PowerShell no-git warning to stderr in JSON mode so stdout stays valid JSON --------- Co-authored-by: Manfred Riem <15701806+mnriem@users.noreply.github.com>
Spec Kit Extensions
Extension system for Spec Kit - add new functionality without bloating the core framework.
Extension Catalogs
Spec Kit provides two catalog files with different purposes:
Your Catalog (catalog.json)
- Purpose: Default upstream catalog of extensions used by the Spec Kit CLI
- Default State: Empty by design in the upstream project - you or your organization populate a fork/copy with extensions you trust
- Location (upstream):
extensions/catalog.jsonin the GitHub-hosted spec-kit repo - CLI Default: The
specify extensioncommands use the upstream catalog URL by default, unless overridden - Org Catalog: Point
SPECKIT_CATALOG_URLat your organization's fork or hosted catalog JSON to use it instead of the upstream default - Customization: Copy entries from the community catalog into your org catalog, or add your own extensions directly
Example override:
# Override the default upstream catalog with your organization's catalog
export SPECKIT_CATALOG_URL="https://your-org.com/spec-kit/catalog.json"
specify extension search # Now uses your organization's catalog instead of the upstream default
Community Reference Catalog (catalog.community.json)
Note
Community extensions are independently created and maintained by their respective authors. GitHub and the Spec Kit maintainers may review pull requests that add entries to the community catalog for formatting, catalog structure, or policy compliance, but they do not review, audit, endorse, or support the extension code itself. Review extension source code before installation and use at your own discretion.
- Purpose: Browse available community-contributed extensions
- Status: Active - contains extensions submitted by the community
- Location:
extensions/catalog.community.json - Usage: Reference catalog for discovering available extensions
- Submission: Open to community contributions via Pull Request
How It Works:
Making Extensions Available
You control which extensions your team can discover and install:
Option 1: Curated Catalog (Recommended for Organizations)
Populate your catalog.json with approved extensions:
- Discover extensions from various sources:
- Browse
catalog.community.jsonfor community extensions - Find private/internal extensions in your organization's repos
- Discover extensions from trusted third parties
- Browse
- Review extensions and choose which ones you want to make available
- Add those extension entries to your own
catalog.json - Team members can now discover and install them:
specify extension searchshows your curated catalogspecify extension add <name>installs from your catalog
Benefits: Full control over available extensions, team consistency, organizational approval workflow
Example: Copy an entry from catalog.community.json to your catalog.json, then your team can discover and install it by name.
Option 2: Direct URLs (For Ad-hoc Use)
Skip catalog curation - team members install directly using URLs:
specify extension add <extension-name> --from https://github.com/org/spec-kit-ext/archive/refs/tags/v1.0.0.zip
Benefits: Quick for one-off testing or private extensions
Tradeoff: Extensions installed this way won't appear in specify extension search for other team members unless you also add them to your catalog.json.
Available Community Extensions
Note
Community extensions are independently created and maintained by their respective authors. GitHub and the Spec Kit maintainers may review pull requests that add entries to the community catalog for formatting, catalog structure, or policy compliance, but they do not review, audit, endorse, or support the extension code itself. The Community Extensions website is also a third-party resource. Review extension source code before installation and use at your own discretion.
🔍 Browse and search community extensions on the Community Extensions website.
See the Community Extensions section in the main README for the full list of available community-contributed extensions.
For the raw catalog data, see catalog.community.json.
Adding Your Extension
Submission Process
To add your extension to the community catalog:
- Prepare your extension following the Extension Development Guide
- Create a GitHub release for your extension
- Submit a Pull Request that:
- Adds your extension to
extensions/catalog.community.json - Updates this README with your extension in the Available Extensions table
- Adds your extension to
- Wait for review - maintainers will review and merge if criteria are met
See the Extension Publishing Guide for detailed step-by-step instructions.
Submission Checklist
Before submitting, ensure:
- ✅ Valid
extension.ymlmanifest - ✅ Complete README with installation and usage instructions
- ✅ LICENSE file included
- ✅ GitHub release created with semantic version (e.g., v1.0.0)
- ✅ Extension tested on a real project
- ✅ All commands working as documented
Installing Extensions
Once extensions are available (either in your catalog or via direct URL), install them:
# From your curated catalog (by name)
specify extension search # See what's in your catalog
specify extension add <extension-name> # Install by name
# Direct from URL (bypasses catalog)
specify extension add <extension-name> --from https://github.com/<org>/<repo>/archive/refs/tags/<version>.zip
# List installed extensions
specify extension list
For more information, see the Extension User Guide.