b5db159394
* feat(catalog): add Spec Kit Schedule (schedule) community extension CP-SAT scheduler for spec-kit projects with multi-agent task optimization. Adds catalog entry for v0.5.2 release. Pre-flight verification: - archive/refs/tags/v0.5.2.zip resolves (HTTP 200, 718322 bytes, SHA-256 00d4dab1df680e5888e0d0e861eb4696ace00661d40669bf719a75dc379b40b5) - extension.yml schema_version 1.0, id 'schedule', 3 commands (speckit.schedule.run, speckit.schedule.portfolio, speckit.schedule.visualize) - 566 tests passing on Ubuntu 3.10/3.11/3.12 + macOS 3.12 (all blocking) - 92.51% line coverage, mypy --strict on 28 modules - Sigstore attestations via attest-build-provenance@v2 (gh attestation verify exit 0 confirmed) - 4 worked examples + replan demo runnable via bash bin/run-examples.sh License: MIT speckit_version: >=0.4.0 * fix(catalog): update Spec Kit Schedule entry to v0.5.3 v0.5.2 had two real-world install bugs caught when a user tried the documented commands: 1. README/INSTALL showed 'specify extension add --from URL' (missing the EXTENSION positional arg). The canonical form is 'specify extension add schedule --from URL'. Fixed in v0.5.3. 2. Release zip was ~5x bigger than peer extensions due to dev cruft (.github/, tests/, benchmarks/, build metadata). Added .gitattributes export-ignore in v0.5.3, dropping the zip from 718 KB to 590 KB. v0.5.3 archive verified HTTP 200, sigstore attestations active. * fix(catalog): bump Spec Kit Schedule entry to v0.5.4 Adds an opt-in after_tasks hook so users get prompted to run the scheduler immediately after /speckit.tasks, without forcing it. Mirrors the canonical pattern used by the bundled 'git' extension. * fix(catalog): bump Spec Kit Schedule entry to v0.5.5 Documents the after_tasks hook in README and rewrites the /speckit.schedule.portfolio command to autodetect the project's tech stack via solver.autodetect, then refine interactively against the matching recipe in docs/portfolio-design.md, instead of starting from a blank slate. * fix(catalog): bump Spec Kit Schedule entry to v0.6.0 State now encapsulated under .specify/, /speckit.schedule.run is idempotent with auto-bootstrap, and portfolio detection is AI-aware (reads .specify/integration.json and discovers the user's fleet from the canonical location for whichever spec-kit AI assistant they chose: claude, copilot, cursor-agent, gemini, or any of the other 26 supported integrations). * fix(catalog): bump Spec Kit Schedule entry to v0.6.1 Per-AI portfolio templates with verified May 2026 GA models (gpt-5.5 flagship, claude-opus-4-7, gemini-2.5-flash). Critical price unit fix (cost_aware reported $ figures 1000× inflated in v0.6.0). Plus calibration feedback loop and inline summary. * fix(readme): add Spec Kit Schedule row to Community Extensions table Per Copilot review on PR #2473: the publishing guide requires an accepted submission to update both extensions/catalog.community.json AND the root README's Community Extensions table. Without the README row the extension wouldn't appear in the primary browsable list. Inserted alphabetically between 'Spec Diagram' and 'Spec Orchestrator'. Category: process. Effect: Read+Write. * fix(catalog): provides.commands 3→4 (schedule only) + bump top-level updated_at Surgical edit responding to two Copilot review nits on PR #2473. Previous attempt used str.replace too broadly and was reverted — this version uses unique anchors to mutate only the schedule entry and the top-level updated_at field. 1. extensions/catalog.community.json schedule entry had provides.commands: 3, but the extension exposes 4 commands (run, portfolio, visualize, calibrate — calibrate was added in v0.6.0 Build 2 / calibration feedback loop). 2. Top-level catalog updated_at was 2026-05-06T22:28:55Z but per-entry updated_at for our schedule entry is 2026-05-07. Since this PR modifies the catalog, the top-level timestamp advances too. * fix(catalog): bump Spec Kit Schedule entry to v0.6.2 Adds /speckit.schedule.status (5th command) — self-diagnose installation state, distinguishes 'expected-missing' (will bootstrap automatically) from 'missing' (real problem). Closes the audit-tool false-alarm gap where schedule-config.yml absence post-install was misread as broken state. --------- Co-authored-by: Julio César Franco Ardila <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)
Note
Community extensions are independently created and maintained by their respective authors. Maintainers only verify that catalog entries are complete and correctly formatted — 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 issue template
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. Maintainers only verify that catalog entries are complete and correctly formatted — 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
- File an issue using the Extension Submission template with all required metadata
- Wait for review — a maintainer will review the submission, update the catalog, and close the issue
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.