* feat(commands): wire before/after hook events into specify and plan templates Replicates the hook evaluation pattern from tasks.md and implement.md (introduced in PR #1702) into the specify and plan command templates. This completes the hook lifecycle across all SDD phases. Changes: - specify.md: Add before_specify/after_specify hook blocks - plan.md: Add before_plan/after_plan hook blocks - EXTENSION-API-REFERENCE.md: Document new hook events - EXTENSION-USER-GUIDE.md: List all available hook events Fixes #1788 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Mark before_commit/after_commit as planned in extension docs These hook events are defined in the API reference but not yet wired into any core command template. Marking them as planned rather than removing them, since the infrastructure supports them. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix hook enablement to default true when field is absent Matches HookExecutor.get_hooks_for_event() semantics where hooks without an explicit enabled field are treated as enabled. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(docs): mark commit hooks as planned in user guide config example The yaml config comment listed before_commit/after_commit as "Available events" but they are not yet wired into core templates. Moved them to a separate "Planned" line, consistent with the API reference. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(commands): align enabled-filtering semantics across all hook templates tasks.md and implement.md previously said "Filter to only hooks where enabled: true", which would skip hooks that omit the enabled field. Updated to match specify.md/plan.md and HookExecutor's h.get('enabled', True) behavior: filter out only hooks where enabled is explicitly false. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.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)
- 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 --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
The following community-contributed extensions are available in catalog.community.json:
| Extension | Purpose | URL |
|---|---|---|
| Archive Extension | Archive merged features into main project memory. | spec-kit-archive |
| Azure DevOps Integration | Sync user stories and tasks to Azure DevOps work items using OAuth authentication | spec-kit-azure-devops |
| Cleanup Extension | Post-implementation quality gate that reviews changes, fixes small issues (scout rule), creates tasks for medium issues, and generates analysis for large issues | spec-kit-cleanup |
| Cognitive Squad | Multi-agent cognitive system with Triadic Model: understanding, internalization, application — with quality gates, backpropagation verification, and self-healing | cognitive-squad |
| DocGuard — CDD Enforcement | Canonical-Driven Development enforcement. Validates, scores, and traces project documentation with automated checks, AI-driven workflows, and spec-kit hooks. Zero NPM runtime dependencies. | spec-kit-docguard |
| Fleet Orchestrator | Orchestrate a full feature lifecycle with human-in-the-loop gates across all SpecKit phases | spec-kit-fleet |
| Iterate | Iterate on spec documents with a two-phase define-and-apply workflow — refine specs mid-implementation and go straight back to building | spec-kit-iterate |
| Jira Integration | Create Jira Epics, Stories, and Issues from spec-kit specifications and task breakdowns with configurable hierarchy and custom field support | spec-kit-jira |
| Learning Extension | Generate educational guides from implementations and enhance clarifications with mentoring context | spec-kit-learn |
| Project Health Check | Diagnose a Spec Kit project and report health issues across structure, agents, features, scripts, extensions, and git | spec-kit-doctor |
| Project Status | Show current SDD workflow progress — active feature, artifact status, task completion, workflow phase, and extensions summary | spec-kit-status |
| Ralph Loop | Autonomous implementation loop using AI agent CLI | spec-kit-ralph |
| Reconcile Extension | Reconcile implementation drift by surgically updating feature artifacts. | spec-kit-reconcile |
| Retrospective Extension | Post-implementation retrospective with spec adherence scoring, drift analysis, and human-gated spec updates | spec-kit-retrospective |
| Review Extension | Post-implementation comprehensive code review with specialized agents for code quality, comments, tests, error handling, type design, and simplification | spec-kit-review |
| SDD Utilities | Resume interrupted workflows, validate project health, and verify spec-to-task traceability | speckit-utils |
| Spec Sync | Detect and resolve drift between specs and implementation. AI-assisted resolution with human approval | spec-kit-sync |
| Understanding | Automated requirements quality analysis — 31 deterministic metrics against IEEE/ISO standards with experimental energy-based ambiguity detection | understanding |
| V-Model Extension Pack | Enforces V-Model paired generation of development specs and test specs with full traceability | spec-kit-v-model |
| Verify Extension | Post-implementation quality gate that validates implemented code against specification artifacts | spec-kit-verify |
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 --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.