Files
github-spec-kit/extensions
saram ali ba9a8b8e59 fix: suppress CRLF warnings in auto-commit.ps1 (#2258)
* fix: suppress CRLF warnings in auto-commit.ps1 (#2253)

Replace 2> with 2>&1 redirection and  assignment to properly
suppress stderr output including CRLF warnings on Windows. Exit code
logic preserved for change detection.

Fixes #2253

* fix: use SilentlyContinue for CRLF stderr handling, add tests

The 2>&1 approach still raises terminating errors under
$ErrorActionPreference='Stop'.  Instead, temporarily set
SilentlyContinue around all native git calls that may emit
CRLF warnings to stderr (rev-parse, diff, ls-files, add, commit).

Adds 5 pytest tests (TestAutoCommitPowerShellCRLF) that set
core.autocrlf=true with LF-ending files.  On Windows runners
this triggers actual CRLF warnings; on other platforms the tests
pass trivially.

Fixes #2253

* refactor: address Copilot review feedback

- Use 'Continue' instead of 'SilentlyContinue' so error output is
  still captured in $out for diagnostics on real git failures.
- Wrap all three EAP save/restore blocks in try/finally to guarantee
  restoration even on unexpected exceptions.
- Fix CRLF test to commit a tracked LF file first, then modify it,
  so git diff --quiet HEAD actually inspects the tracked change and
  triggers the CRLF warning on Windows.

* test: assert CRLF warning fires on Windows

On Windows, probe git diff stderr before running the script to verify
the test setup actually produces the expected CRLF warning.  This
makes the regression test deterministic on the Windows runner.  On
non-Windows the probe is skipped (warnings don't fire there).

---------

Co-authored-by: Manfred Riem <15701806+mnriem@users.noreply.github.com>
2026-04-17 09:27:45 -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)

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:

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 <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:

  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 <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.