specify-cli 0.11.9__tar.gz → 0.12.0__tar.gz

{specify_cli-0.11.9 → specify_cli-0.12.0}/.devcontainer/post-create.sh

@@ -56,7 +56,7 @@ run_command "npm install -g @jetbrains/junie-cli@latest"
 echo "✅ Done"
 
 echo -e "\n🤖 Installing Pi Coding Agent..."
-run_command "npm install -g @mariozechner/pi-coding-agent@latest"
+run_command "npm install -g @earendil-works/pi-coding-agent@latest"
 echo "✅ Done"
 
 echo -e "\n🤖 Installing Kiro CLI..."

specify_cli-0.12.0/.github/ISSUE_TEMPLATE/bundle_submission.yml

@@ -0,0 +1,293 @@
+name: Bundle Submission
+description: Submit your bundle metadata for community catalog validation
+title: "[Bundle]: Add "
+labels: ["enhancement", "needs-triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for contributing a bundle! This template captures metadata for maintainers to validate formatting, links, component resolution, and installation evidence. Maintainers do not audit, endorse, or support bundle code or installed components.
+
+        **Before submitting:**
+        - Review the [Bundles reference](https://github.com/github/spec-kit/blob/main/docs/reference/bundles.md)
+        - Ensure your bundle has a valid `bundle.yml` manifest
+        - Create a GitHub release with a versioned bundle artifact
+        - Test installation from a downloaded artifact: `specify bundle install ./your-bundle-1.0.0.zip`
+        - If you host a bundle catalog, test catalog installation with `specify bundle catalog add <catalog-url> --id <catalog-id> --policy install-allowed` and `specify bundle install <bundle-id>`
+        - If your bundle depends on components from non-default catalogs, document those catalog URLs and test installation from a clean project
+
+  - type: input
+    id: bundle-id
+    attributes:
+      label: Bundle ID
+      description: Unique bundle identifier; must start and end with a lowercase letter or digit and may contain lowercase letters, digits, dots, underscores, and hyphens between
+      placeholder: "e.g., security-governance-stack"
+    validations:
+      required: true
+
+  - type: input
+    id: bundle-name
+    attributes:
+      label: Bundle Name
+      description: Human-readable bundle name
+      placeholder: "e.g., Security Governance Stack"
+    validations:
+      required: true
+
+  - type: input
+    id: version
+    attributes:
+      label: Version
+      description: Semantic version number
+      placeholder: "e.g., 1.0.0"
+    validations:
+      required: true
+
+  - type: input
+    id: role
+    attributes:
+      label: Role or Team
+      description: Primary role, team, or persona this bundle provisions
+      placeholder: "e.g., security-engineer, product-manager, platform-team"
+    validations:
+      required: true
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: Brief description of the stack this bundle installs
+      placeholder: Installs a security governance stack with compliance presets, review commands, and evidence workflows
+    validations:
+      required: true
+
+  - type: input
+    id: author
+    attributes:
+      label: Author
+      description: Your name or organization
+      placeholder: "e.g., Jane Doe or Acme Corp"
+    validations:
+      required: true
+
+  - type: input
+    id: repository
+    attributes:
+      label: Repository URL
+      description: GitHub repository URL for your bundle source
+      placeholder: "https://github.com/your-org/spec-kit-bundle-your-bundle"
+    validations:
+      required: true
+
+  - type: input
+    id: download-url
+    attributes:
+      label: Download URL
+      description: URL to the versioned bundle artifact generated by `specify bundle build`
+      placeholder: "https://github.com/your-org/spec-kit-bundle-your-bundle/releases/download/v1.0.0/your-bundle-1.0.0.zip"
+    validations:
+      required: true
+
+  - type: input
+    id: documentation
+    attributes:
+      label: Documentation URL
+      description: Link to documentation that explains what the bundle installs and how to use it
+      placeholder: "https://github.com/your-org/spec-kit-bundle-your-bundle/blob/main/README.md"
+    validations:
+      required: true
+
+  - type: input
+    id: license
+    attributes:
+      label: License
+      description: Open source license type
+      placeholder: "e.g., MIT, Apache-2.0"
+    validations:
+      required: true
+
+  - type: input
+    id: speckit-version
+    attributes:
+      label: Required Spec Kit Version
+      description: Minimum Spec Kit version required by the bundle
+      placeholder: "e.g., >=0.9.0"
+    validations:
+      required: true
+
+  - type: input
+    id: integration
+    attributes:
+      label: Integration Target (optional)
+      description: Integration ID if the bundle pins one; leave empty if integration-agnostic
+      placeholder: "e.g., claude, copilot, gemini"
+
+  - type: textarea
+    id: components-provided
+    attributes:
+      label: Components Provided
+      description: List the extensions, presets, workflows, and steps this bundle installs
+      placeholder: |
+        - extensions: sicario-guard@0.5.1
+        - presets: sicario-core@0.5.1, sicario-ai-governance@0.5.1
+        - workflows: evidence-review@1.0.0
+        - steps: threat-model
+    validations:
+      required: true
+
+  - type: textarea
+    id: required-catalogs
+    attributes:
+      label: Required Component Catalogs
+      description: List any non-default catalogs users must add before this bundle can resolve its components; enter "None" if every component resolves from built-in or bundled catalogs
+      placeholder: |
+        - Presets: https://github.com/your-org/your-bundle/releases/download/v1.0.0/presets.json
+        - Extensions: https://github.com/your-org/your-bundle/releases/download/v1.0.0/extensions.json
+    validations:
+      required: true
+
+  - type: textarea
+    id: tags
+    attributes:
+      label: Tags
+      description: 2-5 relevant tags (lowercase, separated by commas)
+      placeholder: "security, governance, compliance"
+    validations:
+      required: true
+
+  - type: textarea
+    id: features
+    attributes:
+      label: Key Features
+      description: List the main capabilities this bundle provides
+      placeholder: |
+        - Installs evidence-first security governance templates
+        - Adds automated bundle verification commands
+        - Pins all components to release-tested versions
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: testing
+    attributes:
+      label: Testing Checklist
+      description: Confirm that your bundle has been tested
+      options:
+        - label: Validation succeeds with `specify bundle validate --path <bundle-directory>`
+          required: true
+        - label: Build succeeds with `specify bundle build --path <bundle-directory>` and produces the submitted artifact
+          required: true
+        - label: Bundle installs successfully from the built artifact
+          required: true
+        - label: The submitted distribution path was tested end to end, including bundle-ID installation from an install-allowed catalog when a catalog entry is proposed
+          required: true
+        - label: Installation was tested in a clean Spec Kit project
+          required: true
+        - label: Required component catalogs are documented and were included in testing, or no extra catalogs are required
+          required: true
+        - label: Documentation is complete and accurate
+          required: true
+
+  - type: checkboxes
+    id: requirements
+    attributes:
+      label: Submission Requirements
+      description: Verify your bundle meets all requirements
+      options:
+        - label: Valid `bundle.yml` manifest included
+          required: true
+        - label: README.md explains the bundle's intended role, installed components, and installation steps
+          required: true
+        - label: LICENSE file included
+          required: true
+        - label: GitHub release created with a version tag
+          required: true
+        - label: Bundle ID matches the manifest and follows naming conventions
+          required: true
+        - label: Every extension, preset, workflow, and step reference is pinned where the manifest requires a version
+          required: true
+
+  - type: textarea
+    id: testing-details
+    attributes:
+      label: Testing Details
+      description: Describe how you tested your bundle
+      placeholder: |
+        **Tested on:**
+        - macOS 15 with Spec Kit v0.9.0
+        - Ubuntu 24.04 with Spec Kit v0.9.0
+
+        **Test project:** [Link or description]
+
+        **Test scenarios:**
+        1. Added required catalogs
+        2. Validated bundle manifest
+        3. Built release artifact
+        4. Installed bundle in a clean project
+        5. Ran the installed commands or workflows
+    validations:
+      required: true
+
+  - type: textarea
+    id: example-usage
+    attributes:
+      label: Example Usage
+      description: Provide a simple example of installing and using your bundle
+      render: markdown
+      placeholder: |
+        ```bash
+        # Add any required component catalogs first
+        specify preset catalog add https://github.com/your-org/your-bundle/releases/download/v1.0.0/presets.json --name your-bundle --install-allowed
+        specify extension catalog add https://github.com/your-org/your-bundle/releases/download/v1.0.0/extensions.json --name your-bundle --install-allowed
+
+        # Install the downloaded bundle artifact
+        curl -L -o your-bundle-1.0.0.zip https://github.com/your-org/your-bundle/releases/download/v1.0.0/your-bundle-1.0.0.zip
+        specify bundle install ./your-bundle-1.0.0.zip
+
+        # Or test through an install-allowed bundle catalog
+        specify bundle catalog add https://github.com/your-org/your-bundle/releases/download/v1.0.0/bundles.json --id your-bundle-catalog --policy install-allowed
+        specify bundle install your-bundle
+        ```
+    validations:
+      required: true
+
+  - type: textarea
+    id: catalog-entry
+    attributes:
+      label: Proposed Catalog Entry
+      description: Provide the JSON entry that would appear under the top-level `bundles` object in a bundle catalog (helps reviewers)
+      render: json
+      placeholder: |
+        {
+          "your-bundle": {
+            "name": "Your Bundle",
+            "id": "your-bundle",
+            "version": "1.0.0",
+            "role": "security-engineer",
+            "description": "Brief description of the stack",
+            "author": "Your Name",
+            "license": "MIT",
+            "download_url": "https://github.com/your-org/your-bundle/releases/download/v1.0.0/your-bundle-1.0.0.zip",
+            "repository": "https://github.com/your-org/your-bundle",
+            "requires": {
+              "speckit_version": ">=0.9.0"
+            },
+            "provides": {
+              "extensions": 1,
+              "presets": 2,
+              "steps": 0,
+              "workflows": 1
+            },
+            "tags": ["security", "governance"],
+            "verified": false
+          }
+        }
+    validations:
+      required: true
+
+  - type: textarea
+    id: additional-context
+    attributes:
+      label: Additional Context
+      description: Any other information that would help reviewers
+      placeholder: Screenshots, demo videos, links to related projects, dependency-resolution notes, etc.

{specify_cli-0.11.9 → specify_cli-0.12.0}/AGENTS.md

@@ -75,7 +75,6 @@ class WindsurfIntegration(MarkdownIntegration):
         "args": "$ARGUMENTS",
         "extension": ".md",
     }
-    context_file = ".windsurf/rules/specify-rules.md"
 ```
 
 **TOML agent (Gemini):**
@@ -101,7 +100,6 @@ class GeminiIntegration(TomlIntegration):
         "args": "{{args}}",
         "extension": ".toml",
     }
-    context_file = "GEMINI.md"
 ```
 
 **Skills agent (Codex):**
@@ -129,7 +127,6 @@ class CodexIntegration(SkillsIntegration):
         "args": "$ARGUMENTS",
         "extension": "/SKILL.md",
     }
-    context_file = "AGENTS.md"
 
     @classmethod
     def options(cls) -> list[IntegrationOption]:
@@ -150,7 +147,6 @@ class CodexIntegration(SkillsIntegration):
 | `key` | Class attribute | Unique identifier; for CLI-based integrations (`requires_cli: True`), must match the CLI executable name |
 | `config` | Class attribute (dict) | Agent metadata: `name`, `folder`, `commands_subdir`, `install_url`, `requires_cli` |
 | `registrar_config` | Class attribute (dict) | Command output config: `dir`, `format`, `args` placeholder, file `extension` |
-| `context_file` | Class attribute (str or None) | Path to agent context/instructions file (e.g., `"CLAUDE.md"`, `".github/copilot-instructions.md"`) |
 
 **Key design rule:** For CLI-based integrations (`requires_cli: True`), `key` must be the actual executable name (e.g., `"cursor-agent"` not `"cursor"`). This ensures `shutil.which(key)` works for CLI-tool checks without special-case mappings. IDE-based integrations (`requires_cli: False`) should use their canonical identifier (e.g., `"windsurf"`, `"copilot"`).
 
@@ -175,9 +171,11 @@ def _register_builtins() -> None:
 
 ### 4. Context file behavior
 
-Set `context_file` on the integration class. The base integration setup creates or updates the managed Spec Kit section in that file, and uninstall removes the managed section when appropriate.
+The Specify CLI carries **no agent-context state whatsoever**. Integration classes do **not** declare a `context_file`, and the CLI never creates, updates, removes, resolves, or migrates a context/instruction file (`CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`, …). New integrations add nothing for context handling.
 
-The managed section is owned by the bundled `agent-context` extension (`extensions/agent-context/`). All configuration flows through the extension's own config file at `.specify/extensions/agent-context/agent-context-config.yml`:
+Managing the "Spec Kit" section in the context file is fully owned by the bundled `agent-context` extension (`extensions/agent-context/`), which is a **full opt-in**: `specify init` does not install it. A user adds/enables it through the standard extension verbs, after which the extension's own bundled scripts maintain the context section. When the extension is absent or disabled, nothing in Spec Kit touches the context file.
+
+The extension reads its own config file at `.specify/extensions/agent-context/agent-context-config.yml`:
 
 ```yaml
 # Path to the coding agent context file managed by this extension
@@ -189,10 +187,10 @@ context_markers:
   end: "<!-- SPECKIT END -->"
 ```
 
-- `context_file` is written automatically from the integration's class attribute when `specify init` or `specify integration use` is run.
-- `context_markers.{start,end}` defaults to `IntegrationBase.CONTEXT_MARKER_START` / `CONTEXT_MARKER_END`. Users who want custom markers edit `agent-context-config.yml` directly — both the Python layer (`upsert_context_section()` / `remove_context_section()`) and the bundled scripts (`extensions/agent-context/scripts/bash/update-agent-context.sh` and `.ps1`) read from this single source of truth.
+- The Specify CLI does **not** write this config. When `context_file` is empty, the extension's bundled scripts self-seed it by looking up the active integration's key in the extension's own `agent-context-defaults.json` map (`extensions/agent-context/scripts/bash/update-agent-context.sh` and `.ps1`). The CLI registry is never consulted — all agent→context-file knowledge lives inside the extension.
+- `context_markers.{start,end}` are read solely by the extension's scripts; they default to the Spec Kit markers shown above and can be customized by editing `agent-context-config.yml` directly.
 
-Users can opt out entirely with `specify extension disable agent-context`; while disabled, Spec Kit skips context-file creation, updates, and removal (the gates are inside `upsert_context_section()` and `remove_context_section()`).
+Existing projects created by older Spec Kit versions keep working: any previously written managed section or extension config is left intact and is only ever updated by the extension when run.
 
 Only add custom setup logic when the agent needs non-standard behavior. Integrations no longer require per-agent thin wrapper scripts or shared context-update dispatcher scripts — the `agent-context` extension is fully generic.
 
@@ -401,7 +399,6 @@ Implementation: Extends `YamlIntegration` (parallel to `TomlIntegration`):
 2. Extracts title and description from frontmatter
 3. Renders output as Goose recipe YAML (version, title, description, author, extensions, activities, prompt)
 4. Uses `yaml.safe_dump()` for header fields to ensure proper escaping
-5. Sets `context_file = "AGENTS.md"` so the base setup manages the Spec Kit context section there
 
 ## Branch Naming Convention
 
@@ -466,7 +463,7 @@ Disclosure is **continuous**, not a one-time event. A single AI-disclosure parag
 ## Common Pitfalls
 
 1. **Using shorthand keys for CLI-based integrations**: For CLI-based integrations (`requires_cli: True`), the `key` must match the executable name (e.g., `"cursor-agent"` not `"cursor"`). `shutil.which(key)` is used for CLI tool checks — mismatches require special-case mappings. IDE-based integrations (`requires_cli: False`) are not subject to this constraint.
-2. **Forgetting context configuration**: The bundled `agent-context` extension reads from `.specify/extensions/agent-context/agent-context-config.yml`. New integrations only need to set `context_file` on the class — markers and dispatcher scripts are managed centrally.
+2. **Reintroducing context handling into the CLI**: The opt-in `agent-context` extension owns everything about context files — including the per-agent default mapping in `agent-context-defaults.json`. Integration classes must **not** declare a `context_file`, and no CLI code should read, write, resolve, or migrate context files. All context-file logic lives in `.specify/extensions/agent-context/` and its bundled scripts.
 3. **Incorrect `requires_cli` value**: Set to `True` only for agents that have a CLI tool; set to `False` for IDE-based agents.
 4. **Wrong argument format**: Use `$ARGUMENTS` for Markdown agents, `{{args}}` for TOML agents.
 5. **Skipping registration**: The import and `_register()` call in `_register_builtins()` must both be added.

{specify_cli-0.11.9 → specify_cli-0.12.0}/CHANGELOG.md

@@ -2,6 +2,37 @@
 
 <!-- insert new changelog below this comment -->
 
+## [0.12.0] - 2026-06-29
+
+### Changed
+
+- feat: make agent-context extension a full opt-in (#3097)
+- docs(workflows): add the built-in 'init' step type to the Step Types table (#3234)
+- fix(workflows): gate validate() must not crash on non-string options (#3233)
+- fix(workflows): make pipe-filter detection quote-aware in expressions (#3232)
+- fix(workflows): reject a fan-in wait_for that names an unknown step at validation (#3225)
+- fix(scripts): warn when spec template is missing in create-new-feature.ps1 (parity with bash) (#3230)
+- fix(scripts): count subdirectory-only dirs as non-empty in PowerShell (parity with bash) (#3137)
+- fix(scripts): drop HAS_GIT from PowerShell git-extension output (parity with bash) (#3195)
+- Update Product Spec Extension to v1.0.1 (#3226)
+- chore: release 0.11.10, begin 0.11.11.dev0 development (#3240)
+
+## [0.11.10] - 2026-06-29
+
+### Changed
+
+- fix(extensions): apply GHES auth and resolve release assets for `extension add --from` (#3217)
+- fix(pi): repoint install_url to @earendil-works/pi-coding-agent (#3169) (#3214)
+- fix(catalogs): reject host-less catalog URLs in base and preset validators (#3210)
+- fix: update CodeBuddy install docs URL (#3187)
+- fix(workflows): reject infinite number-input default instead of raising OverflowError (#3199)
+- fix(scripts): emit 'Copied plan template' status in setup-plan.ps1 (parity with bash) (#3198)
+- fix(workflows): make expression operator/literal parsing quote-aware (#3197)
+- fix(scripts): honor explicit -Number 0 in PowerShell create-new-feature (parity with bash) (#3196)
+- Add community bundle submission path (#3162)
+- Docs: Document /speckit.converge command (#3181)
+- chore: release 0.11.9, begin 0.11.10.dev0 development (#3189)
+
 ## [0.11.9] - 2026-06-26
 
 ### Changed

{specify_cli-0.11.9 → specify_cli-0.12.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: specify-cli
-Version: 0.11.9
+Version: 0.12.0
 Summary: Specify CLI, part of GitHub Spec Kit. A tool to bootstrap your projects for Spec-Driven Development (SDD).
 License-File: LICENSE
 Requires-Python: >=3.11
@@ -154,13 +154,14 @@ Explore community-contributed resources on the [Spec Kit docs site](https://gith
 
 - [Extensions](https://github.github.io/spec-kit/community/extensions.html) — commands, hooks, and capabilities
 - [Presets](https://github.github.io/spec-kit/community/presets.html) — template and terminology overrides
+- [Bundles](https://github.github.io/spec-kit/community/bundles.html) — role and team stacks composed from existing components
 - [Walkthroughs](https://github.github.io/spec-kit/community/walkthroughs.html) — end-to-end SDD scenarios
 - [Friends](https://github.github.io/spec-kit/community/friends.html) — projects that extend or build on Spec Kit
 
 > [!NOTE]
 > Community contributions are independently created and maintained by their respective authors. Review source code before installation and use at your own discretion.
 
-Want to contribute? See the [Extension Publishing Guide](extensions/EXTENSION-PUBLISHING-GUIDE.md) or the [Presets Publishing Guide](presets/PUBLISHING.md).
+Want to contribute? See the [Extension Publishing Guide](extensions/EXTENSION-PUBLISHING-GUIDE.md), the [Presets Publishing Guide](presets/PUBLISHING.md), or the [Community Bundles guide](docs/community/bundles.md).
 
 ## 🤖 Supported AI Coding Agent Integrations
 
@@ -282,8 +283,10 @@ built-in). Each source carries an install policy: `install-allowed` sources can
 be installed from, while `discovery-only` sources are visible in `search`/`info`
 but refuse installation. Manage the stack with `specify bundle catalog list|add|remove`.
 
-Authors validate and package bundles locally — there is no first-class publish;
-distribution is hosting the built artifact and adding a catalog entry:
+Authors validate and package bundles locally. Distribution is hosting the built
+artifact and adding a catalog source; community bundle submissions use the
+[Bundle Submission](https://github.com/github/spec-kit/issues/new?template=bundle_submission.yml)
+issue template so required component catalogs and install evidence can be reviewed:
 
 ```bash
 specify bundle validate --path ./my-bundle      # structural + reference checks

{specify_cli-0.11.9 → specify_cli-0.12.0}/README.md

@@ -134,13 +134,14 @@ Explore community-contributed resources on the [Spec Kit docs site](https://gith
 
 - [Extensions](https://github.github.io/spec-kit/community/extensions.html) — commands, hooks, and capabilities
 - [Presets](https://github.github.io/spec-kit/community/presets.html) — template and terminology overrides
+- [Bundles](https://github.github.io/spec-kit/community/bundles.html) — role and team stacks composed from existing components
 - [Walkthroughs](https://github.github.io/spec-kit/community/walkthroughs.html) — end-to-end SDD scenarios
 - [Friends](https://github.github.io/spec-kit/community/friends.html) — projects that extend or build on Spec Kit
 
 > [!NOTE]
 > Community contributions are independently created and maintained by their respective authors. Review source code before installation and use at your own discretion.
 
-Want to contribute? See the [Extension Publishing Guide](extensions/EXTENSION-PUBLISHING-GUIDE.md) or the [Presets Publishing Guide](presets/PUBLISHING.md).
+Want to contribute? See the [Extension Publishing Guide](extensions/EXTENSION-PUBLISHING-GUIDE.md), the [Presets Publishing Guide](presets/PUBLISHING.md), or the [Community Bundles guide](docs/community/bundles.md).
 
 ## 🤖 Supported AI Coding Agent Integrations
 
@@ -262,8 +263,10 @@ built-in). Each source carries an install policy: `install-allowed` sources can
 be installed from, while `discovery-only` sources are visible in `search`/`info`
 but refuse installation. Manage the stack with `specify bundle catalog list|add|remove`.
 
-Authors validate and package bundles locally — there is no first-class publish;
-distribution is hosting the built artifact and adding a catalog entry:
+Authors validate and package bundles locally. Distribution is hosting the built
+artifact and adding a catalog source; community bundle submissions use the
+[Bundle Submission](https://github.com/github/spec-kit/issues/new?template=bundle_submission.yml)
+issue template so required component catalogs and install evidence can be reviewed:
 
 ```bash
 specify bundle validate --path ./my-bundle      # structural + reference checks

specify_cli-0.12.0/docs/community/bundles.md

@@ -0,0 +1,53 @@
+# Community Bundles
+
+> [!NOTE]
+> Community bundles are independently created and maintained by their respective authors. Maintainers only verify that submission metadata is complete and correctly formatted — they do **not review, audit, endorse, or support the bundle code or the components it installs**. Review bundle manifests, component catalogs, and source repositories before installation and use at your own discretion.
+
+Bundles compose existing Spec Kit components — extensions, presets, workflows, and steps — into a single role or team stack. They are useful when a user should be able to install a tested set of components together instead of following several separate install commands.
+
+Accepted community bundle entries will be listed here once a community bundle catalog is available. To submit a bundle for review, file a [Bundle Submission](https://github.com/github/spec-kit/issues/new?template=bundle_submission.yml) issue.
+
+## What to Submit
+
+A bundle submission should include:
+
+- A public repository with a valid `bundle.yml` manifest.
+- A versioned GitHub release with a bundle artifact created by `specify bundle build`.
+- Documentation that explains the intended role, installed components, required catalogs, and expected workflow.
+- A proposed catalog entry with bundle metadata and component counts.
+- Test evidence from a clean Spec Kit project.
+
+## Component Resolution
+
+A bundle catalog entry describes where to download the bundle artifact, but the bundle's component references still need to resolve when a user installs it. References can resolve from bundled components, already installed components, or active extension, preset, workflow, and step catalogs.
+
+If your bundle depends on components that are not available from the default Spec Kit catalogs, include the required catalog URLs in the submission and in your README. Test the full install path from a clean project with those catalogs added before submitting.
+
+For example:
+
+```bash
+specify preset catalog add https://example.com/presets.json --name example-bundle --install-allowed
+specify extension catalog add https://example.com/extensions.json --name example-bundle --install-allowed
+curl -L -o example-bundle-1.0.0.zip https://example.com/example-bundle-1.0.0.zip
+specify bundle install ./example-bundle-1.0.0.zip
+
+# Or install by id from an install-allowed bundle catalog.
+specify bundle catalog add https://example.com/bundles.json --id example-bundle-catalog --policy install-allowed
+specify bundle install example-bundle
+```
+
+## Review Scope
+
+Maintainers check that:
+
+- The submission fields are complete and correctly formatted.
+- The release artifact and documentation URLs are reachable.
+- The repository contains a `bundle.yml` manifest.
+- The submission clearly identifies any required component catalogs.
+- The proposed catalog entry uses the expected bundle catalog entry shape.
+
+Maintainers do not audit the behavior of installed extensions, presets, workflows, steps, or scripts. Users should review those components before installing a community bundle.
+
+## Updating a Bundle
+
+To update a submitted bundle, file another [Bundle Submission](https://github.com/github/spec-kit/issues/new?template=bundle_submission.yml) issue with the new version, download URL, changed component list, and updated test evidence. Mention that the issue updates an existing bundle entry.

{specify_cli-0.11.9 → specify_cli-0.12.0}/docs/community/overview.md

@@ -1,6 +1,6 @@
 # Community
 
-The Spec Kit community builds extensions, presets, walkthroughs, and companion projects that expand what you can do with Spec-Driven Development. All community contributions are independently created and maintained by their respective authors.
+The Spec Kit community builds extensions, presets, bundles, walkthroughs, and companion projects that expand what you can do with Spec-Driven Development. All community contributions are independently created and maintained by their respective authors.
 
 ## Extensions
 
@@ -14,6 +14,12 @@ Presets customize how Spec Kit behaves — overriding templates, commands, and t
 
 [Browse community presets →](presets.md)
 
+## Bundles
+
+Bundles compose extensions, presets, workflows, and steps into role or team stacks that can be installed together.
+
+[Browse community bundles →](bundles.md)
+
 ## Walkthroughs
 
 Step-by-step guides that show Spec-Driven Development in action across different scenarios, languages, and frameworks.

{specify_cli-0.11.9 → specify_cli-0.12.0}/docs/guides/evolving-specs.md

@@ -26,6 +26,7 @@ through the standard flow:
 2. Run `/speckit.plan` to define the implementation approach.
 3. Run `/speckit.tasks` to derive the work breakdown.
 4. Run `/speckit.implement` and review the resulting code and artifact diffs.
+5. Run `/speckit.converge` to verify completeness and generate tasks for remaining gaps. If tasks are appended, repeat `/speckit.implement` and `/speckit.converge` until the feature is fully complete.
 
 The previous feature directory remains intact for audit, comparison, or
 explaining how the project reached its current state. Use clear feature names or
@@ -50,6 +51,7 @@ spec:
 5. Run `/speckit.analyze` before implementation resumes to catch gaps between
    the spec, plan, and tasks.
 6. Run `/speckit.implement`, then review the code and artifact diffs together.
+7. Run `/speckit.converge` to assess completion and append any remaining work to `tasks.md`. If tasks are appended, repeat `/speckit.implement` and `/speckit.converge` until the feature is fully complete.
 
 Preserve important implementation rationale before replacing derived artifacts.
 If a plan or task list contains decisions that still matter, carry them forward

{specify_cli-0.11.9 → specify_cli-0.12.0}/docs/installation.md

@@ -94,8 +94,15 @@ This helps verify you are running the official Spec Kit build from GitHub, not a
 After initialization, you should see the following commands available in your coding agent:
 
 - `/speckit.specify` - Create specifications
-- `/speckit.plan` - Generate implementation plans  
+- `/speckit.plan` - Generate implementation plans
 - `/speckit.tasks` - Break down into actionable tasks
+- `/speckit.implement` - Execute implementation tasks
+- `/speckit.analyze` - Validate cross-artifact consistency
+- `/speckit.clarify` - Identify and resolve ambiguities
+- `/speckit.checklist` - Generate quality checklists
+- `/speckit.constitution` - Create or update project principles
+- `/speckit.converge` - Assess codebase against artifacts and append remaining tasks
+- `/speckit.taskstoissues` - Convert tasks to issues
 
 Scripts are installed into a variant subdirectory matching the chosen script type:
 

{specify_cli-0.11.9 → specify_cli-0.12.0}/docs/quickstart.md

@@ -13,10 +13,10 @@ This guide will help you get started with Spec-Driven Development using Spec Kit
 After installing Spec Kit and defining your project constitution, quick experiments can use the lean feature path: `/speckit.specify` -> `/speckit.plan` -> `/speckit.tasks` -> `/speckit.implement`. For production features or any work with meaningful ambiguity, treat `/speckit.clarify`, `/speckit.checklist`, and `/speckit.analyze` as regular quality gates:
 
 ```text
-/speckit.constitution -> /speckit.specify -> /speckit.clarify -> /speckit.plan -> /speckit.checklist -> /speckit.tasks -> /speckit.analyze -> /speckit.implement
+/speckit.constitution -> /speckit.specify -> /speckit.clarify -> /speckit.plan -> /speckit.checklist -> /speckit.tasks -> /speckit.analyze -> /speckit.implement -> /speckit.converge
 ```
 
-Use `/speckit.clarify` to reduce requirement ambiguity before planning, `/speckit.checklist` (after `/speckit.plan`) to generate quality checklists that validate requirements completeness, clarity, and consistency, and `/speckit.analyze` to check spec/plan/task consistency before implementation starts. You can repeat `/speckit.analyze` after implementation as an extra review, but keep the first analysis before `/speckit.implement` so gaps are caught while the plan and tasks can still be adjusted.
+Use `/speckit.clarify` to reduce requirement ambiguity before planning, `/speckit.checklist` (after `/speckit.plan`) to generate quality checklists that validate requirements completeness, clarity, and consistency, and `/speckit.analyze` to check spec/plan/task consistency before implementation starts. You can repeat `/speckit.analyze` after implementation as an extra review, but keep the first analysis before `/speckit.implement` so gaps are caught while the plan and tasks can still be adjusted. Finally, run `/speckit.converge` after implementation to verify all planned work is complete and generate tasks for any remaining gaps. If `/speckit.converge` appends new tasks, run `/speckit.implement` again (and converge again) until it reports that the feature has converged.
 
 ### Step 1: Install Specify
 
@@ -188,6 +188,14 @@ Finally, implement the solution:
 /speckit.implement
 ```
 
+### Step 8: Converge
+
+Run the `/speckit.converge` command after implementation to assess the current codebase against the feature's artifacts and append any remaining unbuilt work as new tasks to `tasks.md`. If the command appends new tasks, run `/speckit.implement` again to complete them, and repeat the converge step until the feature is fully complete.
+
+```bash
+/speckit.converge
+```
+
 > [!TIP]
 > **Phased Implementation**: For large projects like Taskify, consider implementing in phases (e.g., Phase 1: Basic project/task structure, Phase 2: Kanban functionality, Phase 3: Comments and assignments). This prevents context saturation and allows for validation at each stage.
 

{specify_cli-0.11.9 → specify_cli-0.12.0}/docs/reference/bundles.md

@@ -119,6 +119,12 @@ specify bundle build
 
 Produces a single versioned, distributable `.zip` artifact from a bundle directory. The artifact embeds the manifest and can be installed directly with `specify bundle install <artifact.zip>`.
 
+## Publish a Bundle
+
+Bundle authors validate and package bundles locally, then host the generated artifact and catalog metadata where users can access it. A bundle catalog entry points at the bundle artifact, but the components declared inside `bundle.yml` still resolve through bundled components, installed components, or active extension, preset, workflow, and step catalogs.
+
+If your bundle references components from non-default catalogs, document those catalog URLs and test the install path from a clean project with those catalogs added. Community bundle submissions should include that dependency-resolution evidence in the [Bundle Submission](https://github.com/github/spec-kit/issues/new?template=bundle_submission.yml) issue.
+
 ## Manage Catalog Sources
 
 Bundles are discovered through a priority-ordered stack of catalog sources (project, user, and built-in scopes).