Files
spec-kit/extensions
Michal Bachorik 58ce653908 feat(extensions): Quality of life improvements for RFC-aligned catalog integration (#1776)
* feat(extensions): implement automatic updates with atomic backup/restore

- Implement automatic extension updates with download from catalog
- Add comprehensive backup/restore mechanism for failed updates:
  - Backup registry entry before update
  - Backup extension directory
  - Backup command files for all AI agents
  - Backup hooks from extensions.yml
- Add extension ID verification after install
- Add KeyboardInterrupt handling to allow clean cancellation
- Fix enable/disable to preserve installed_at timestamp by using
  direct registry manipulation instead of registry.add()
- Add rollback on any update failure with command file,
  hook, and registry restoration

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): comprehensive name resolution and error handling improvements

- Add shared _resolve_installed_extension helper for ID/display name resolution
  with proper ambiguous name handling (shows table of matches)
- Add _resolve_catalog_extension helper for catalog lookups by ID or display name
- Update enable/disable/update/remove commands to use name resolution helpers
- Fix extension_info to handle catalog errors gracefully:
  - Fallback to local installed info when catalog unavailable
  - Distinguish "catalog unavailable" from "not found in catalog"
  - Support display name lookup for both installed and catalog extensions
- Use resolved display names in all status messages for consistency
- Extract _print_extension_info helper for DRY catalog info printing

Addresses reviewer feedback:
- Ambiguous name handling in enable/disable/update
- Catalog error fallback for installed extensions
- UX message clarity (catalog unavailable vs not found)
- Resolved ID in status messages

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): properly detect ambiguous names in extension_info

The extension_info command was breaking on the first name match without
checking for ambiguity. This fix separates ID matching from name matching
and checks for ambiguity before selecting a match, consistent with the
_resolve_installed_extension() helper used by other commands.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* refactor(extensions): add public update() method to ExtensionRegistry

Add a proper public API for updating registry metadata while preserving
installed_at timestamp, instead of directly mutating internal registry
data and calling private _save() method.

Changes:
- Add ExtensionRegistry.update() method that preserves installed_at
- Update enable/disable commands to use registry.update()
- Update rollback logic to use registry.update()

This decouples the CLI from registry internals and maintains proper
encapsulation.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): safely access optional author field in extension_info

ExtensionManifest doesn't expose an author property - the author field
is optional in extension.yml and stored in data["extension"]["author"].
Use safe dict access to avoid AttributeError.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): address multiple reviewer comments

- ExtensionRegistry.update() now preserves original installed_at timestamp
- Add ExtensionRegistry.restore() for rollback (entry was removed)
- Clean up wrongly installed extension on ID mismatch before rollback
- Remove unused catalog_error parameter from _print_extension_info()

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): check _install_allowed for updates, preserve backup on failed rollback

- Skip automatic updates for extensions from catalogs with install_allowed=false
- Only delete backup directory on successful rollback, preserve it on failure
  for manual recovery

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): address reviewer feedback on update/rollback logic

- Hook rollback: handle empty backup_hooks by checking `is not None`
  instead of truthiness (falsy empty dict would skip hook cleanup)
- extension_info: use resolved_installed_id for catalog lookup when
  extension was found by display name (prevents wrong catalog match)
- Rollback: always remove extension dir first, then restore if backup
  exists (handles case when no original dir existed before update)
- Validate extension ID from ZIP before installing, not after
  (avoids side effects of installing wrong extension before rollback)
- Preserve enabled state during updates: re-apply disabled state and
  hook enabled flags after successful update
- Optimize _resolve_catalog_extension: pass query to catalog.search()
  instead of fetching all extensions
- update() now merges metadata with existing entry instead of replacing
  (preserves fields like registered_commands when only updating enabled)
- Add tests for ExtensionRegistry.update() and restore() methods:
  - test_update_preserves_installed_at
  - test_update_merges_with_existing
  - test_update_raises_for_missing_extension
  - test_restore_overwrites_completely
  - test_restore_can_recreate_removed_entry

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs(extensions): update RFC to reflect implemented status

- Change status from "Draft" to "Implemented"
- Update all Implementation Phases to show completed items
- Add new features implemented beyond original RFC:
  - Display name resolution for all commands
  - Ambiguous name handling with tables
  - Atomic update with rollback
  - Pre-install ID validation
  - Enabled state preservation
  - Registry update/restore methods
  - Catalog error fallback
  - _install_allowed flag
  - Cache invalidation
- Convert Open Questions to Resolved Questions with decisions
- Add remaining Open Questions (sandboxing, signatures) as future work
- Fix table of contents links

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): address third round of PR review comments

- Refactor extension_info to use _resolve_installed_extension() helper
  with new allow_not_found parameter instead of duplicating resolution logic
- Fix rollback hook restoration to not create empty hooks: {} in config
  when original config had no hooks section
- Fix ZIP pre-validation to handle nested extension.yml files (GitHub
  auto-generated ZIPs have structure like repo-name-branch/extension.yml)
- Replace unused installed_manifest variable with _ placeholder
- Add display name to update status messages for better UX

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(extensions): address fourth round of PR review comments

Rollback fixes:
- Preserve installed_at timestamp after successful update (was reset by
  install_from_zip calling registry.add)
- Fix rollback to only delete extension_dir if backup exists (avoids
  destroying valid installation when failure happens before modification)
- Fix rollback to remove NEW command files created by failed install
  (files that weren't in original backup are now cleaned up)
- Fix rollback to delete hooks key entirely when backup_hooks is None
  (original config had no hooks key, so restore should remove it)

Cross-command consistency fix:
- Add display name resolution to `extension add` command using
  _resolve_catalog_extension() helper (was only in `extension info`)
- Use resolved extension ID for download_extension() call, not original
  argument which may be a display name

Security fix (fail-closed):
- Malformed catalog config (empty/missing URLs) now raises ValidationError
  instead of silently falling back to built-in catalogs

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(lint): address ruff linting errors and registry.update() semantics

- Remove unused import ExtensionError in extension_info
- Remove extraneous f-prefix from strings without placeholders
- Use registry.restore() instead of registry.update() for installed_at
  preservation (update() always preserves existing installed_at, ignoring
  our override)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

---------

Co-authored-by: iamaeroplane <michal.bachorik@gmail.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-03-13 07:23:37 -05:00
..

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.json in the GitHub-hosted spec-kit repo
  • CLI Default: The specify extension commands use the upstream catalog URL by default, unless overridden
  • Org Catalog: Point SPECKIT_CATALOG_URL at 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:

Populate your catalog.json with approved extensions:

  1. Discover extensions from various sources:
    • Browse catalog.community.json for community extensions
    • Find private/internal extensions in your organization's repos
    • Discover extensions from trusted third parties
  2. Review extensions and choose which ones you want to make available
  3. Add those extension entries to your own catalog.json
  4. Team members can now discover and install them:
    • specify extension search shows your curated catalog
    • specify 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
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
Fleet Orchestrator Orchestrate a full feature lifecycle with human-in-the-loop gates across all SpecKit phases spec-kit-fleet
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
Ralph Loop Autonomous implementation loop using AI agent CLI spec-kit-ralph
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
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:

  1. Prepare your extension following the Extension Development Guide
  2. Create a GitHub release for your extension
  3. Submit a Pull Request that:
    • Adds your extension to extensions/catalog.community.json
    • Updates this README with your extension in the Available Extensions table
  4. 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.yml manifest
  • 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.