specify-cli 0.11.3__tar.gz → 0.11.4__tar.gz

specify_cli-0.11.4/.gitattributes

@@ -0,0 +1,7 @@
+* text=auto eol=lf
+
+.github/workflows/*.lock.yml linguist-generated=true merge=ours -whitespace
+# The project constitution is the one dogfooding artifact carried forward.
+# Keep it exempt from git's whitespace checks (git diff --check / CI) since its
+# generated formatting is not hand-edited.
+.specify/memory/constitution.md -whitespace

{specify_cli-0.11.3 → specify_cli-0.11.4}/.gitignore

@@ -10,8 +10,8 @@ dist/
 downloads/
 eggs/
 .eggs/
-lib/
-lib64/
+/lib/
+/lib64/
 parts/
 sdist/
 var/

{specify_cli-0.11.3 → specify_cli-0.11.4}/AGENTS.md

@@ -14,7 +14,7 @@ The toolkit supports multiple AI coding assistants, allowing teams to use their
 
 Each AI agent is a self-contained **integration subpackage** under `src/specify_cli/integrations/<key>/`. The subpackage exposes a single class that declares all metadata and inherits setup/teardown logic from a base class. Built-in integrations are then instantiated and added to the global `INTEGRATION_REGISTRY` by `src/specify_cli/integrations/__init__.py` via `_register_builtins()`.
 
-```
+```text
 src/specify_cli/integrations/
 ├── __init__.py            # INTEGRATION_REGISTRY + _register_builtins()
 ├── base.py                # IntegrationBase, MarkdownIntegration, TomlIntegration, YamlIntegration, SkillsIntegration
@@ -340,18 +340,21 @@ Some agents require custom processing beyond the standard template transformatio
 ### Copilot Integration
 
 GitHub Copilot has unique requirements:
+
 - Commands use `.agent.md` extension (not `.md`)
 - Each command gets a companion `.prompt.md` file in `.github/prompts/`
 - Installs `.vscode/settings.json` with prompt file recommendations
 - Context file lives at `.github/copilot-instructions.md`
 
 Implementation: Extends `IntegrationBase` with custom `setup()` method that:
+
 1. Processes templates with `process_template()`
 2. Generates companion `.prompt.md` files
 3. Merges VS Code settings
 
 **Skills mode (`--skills`):** Copilot also supports an alternative skills-based layout
 via `--integration-options="--skills"`. When enabled:
+
 - Commands are scaffolded as `speckit-<name>/SKILL.md` under `.github/skills/`
 - No companion `.prompt.md` files are generated
 - No `.vscode/settings.json` merge
@@ -371,11 +374,13 @@ specify init my-project --integration copilot --integration-options="--skills"
 ### Forge Integration
 
 Forge has special frontmatter and argument requirements:
+
 - Uses `{{parameters}}` instead of `$ARGUMENTS`
 - Strips `handoffs` frontmatter key (Forge-specific collaboration feature)
 - Injects `name` field into frontmatter when missing
 
 Implementation: Extends `MarkdownIntegration` with custom `setup()` method that:
+
 1. Inherits standard template processing from `MarkdownIntegration`
 2. Adds extra `$ARGUMENTS` → `{{parameters}}` replacement after template processing
 3. Applies Forge-specific transformations via `_apply_forge_transformations()`
@@ -385,11 +390,13 @@ Implementation: Extends `MarkdownIntegration` with custom `setup()` method that:
 ### Goose Integration
 
 Goose is a YAML-format agent using Block's recipe system:
+
 - Uses `.goose/recipes/` directory for YAML recipe files
 - Uses `{{args}}` argument placeholder
 - Produces YAML with `prompt: |` block scalar for command content
 
 Implementation: Extends `YamlIntegration` (parallel to `TomlIntegration`):
+
 1. Processes templates through the standard placeholder pipeline
 2. Extracts title and description from frontmatter
 3. Renders output as Goose recipe YAML (version, title, description, author, extensions, activities, prompt)
@@ -400,7 +407,7 @@ Implementation: Extends `YamlIntegration` (parallel to `TomlIntegration`):
 
 Branches follow one of two patterns depending on whether an issue exists:
 
-```
+```text
 <type>/<number>-<short-slug>   # when an issue is created first
 <type>/<short-slug>            # when no issue exists (PR-only changes)
 ```
@@ -463,6 +470,7 @@ Disclosure is **continuous**, not a one-time event. A single AI-disclosure parag
 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.
+6. **Running tests against the wrong environment**: Always run the suite inside this working tree's own virtualenv (`uv sync --extra test` then `.venv/bin/python -m pytest`, or activate the venv first). A bare `uv run pytest` can resolve to an ambient/global interpreter whose editable `.pth` points at a *different* worktree. The failure is sneaky: test collection still imports `specify_cli` successfully, but newly-added subpackages (e.g. a fresh `specify_cli/bundler/`) resolve as a stale namespace package and raise `ModuleNotFoundError`. If a brand-new subpackage imports under `python -c` but not under pytest, suspect environment contamination, not your code.
 
 ---
 

{specify_cli-0.11.3 → specify_cli-0.11.4}/CHANGELOG.md

@@ -2,6 +2,21 @@
 
 <!-- insert new changelog below this comment -->
 
+## [0.11.4] - 2026-06-22
+
+### Changed
+
+- [extension] Add Tasks to GitHub Project extension to community catalog (#3090)
+- Update Linear Integration extension to v0.7.0 (#3089)
+- fix: fail loudly on an unknown workflow expression filter (#3074)
+- fix: anchor lib/ and lib64/ patterns to repo root in .gitignore (#3083)
+- fix(build): include specify_cli.bundler.lib in built distribution (#3085)
+- Harden command registration path handling (#3088)
+- fix(presets): preserve argument-hint in preset SKILL.md generation (#2978)
+- feat: surface gate detail in the workflow run/resume --json payload (#2965)
+- feat: add `specify bundle` command (#3070)
+- chore: release 0.11.3, begin 0.11.4.dev0 development (#3072)
+
 ## [0.11.3] - 2026-06-19
 
 ### Changed
@@ -17,8 +32,6 @@
 - Add Token Economy extension to community catalog (#3049)
 - chore: release 0.11.2, begin 0.11.3.dev0 development (#3059)
 
-- feat(scripts): add SPECIFY_INIT_DIR to target a member project from the repo root (#2892)
-
 ## [0.11.2] - 2026-06-18
 
 ### Changed

{specify_cli-0.11.3 → specify_cli-0.11.4}/CONTRIBUTING.md

@@ -95,6 +95,24 @@ uv run python -m pytest tests/test_agent_config_consistency.py -q
 
 Run this when you change agent metadata, context update scripts, or integration wiring.
 
+#### Running the full test suite
+
+Install the test dependencies into the project's own virtual environment and run
+`pytest` through that interpreter:
+
+```bash
+uv pip install -e ".[test]"
+.venv/bin/python -m pytest tests -q   # Windows: .venv\Scripts\python -m pytest tests -q
+```
+
+> **Note:** prefer `.venv/bin/python -m pytest` over a bare `uv run pytest`.
+> If another Spec Kit checkout has an editable (`-e`) install registered in a
+> shared/global environment, `uv run pytest` can resolve `specify_cli` to that
+> *other* worktree, turning it into a partial namespace package that fails to
+> import newly added subpackages. Running through the project `.venv` resolves
+> `specify_cli` to this checkout's `src/`. This matches the gotcha documented in
+> `AGENTS.md` (Common Pitfalls).
+
 ### Manual testing
 
 #### Testing setup

{specify_cli-0.11.3 → specify_cli-0.11.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: specify-cli
-Version: 0.11.3
+Version: 0.11.4
 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
@@ -46,6 +46,7 @@ Description-Content-Type: text/markdown
 - [🤖 Supported AI Coding Agent Integrations](#-supported-ai-coding-agent-integrations)
 - [🔧 Specify CLI Reference](#-specify-cli-reference)
 - [🧩 Making Spec Kit Your Own: Extensions & Presets](#-making-spec-kit-your-own-extensions--presets)
+- [📦 Bundles: Role-Based Setups](#-bundles-role-based-setups)
 - [📚 Core Philosophy](#-core-philosophy)
 - [🌟 Development Phases](#-development-phases)
 - [🎯 Experimental Goals](#-experimental-goals)
@@ -248,6 +249,56 @@ For example, presets could restructure spec templates to require regulatory trac
 
 See the [Presets reference](https://github.github.io/spec-kit/reference/presets.html) for the full command guide, including resolution order and priority stacking.
 
+## 📦 Bundles: Role-Based Setups
+
+Extensions and presets are individual building blocks. A **bundle** packages a
+curated set of them — extensions, presets, steps, and workflows — into a single,
+versioned, role-oriented setup so a whole team persona (product manager, business
+analyst, security researcher, developer, …) can be provisioned with one command.
+
+A bundle is described by a hand-written `bundle.yml` manifest. It pins each
+component to a version and, optionally, targets a specific integration; a bundle
+with no `integration` is **agnostic** and inherits whatever integration the
+project already uses.
+
+```bash
+# Discover bundles in the active catalog stack
+specify bundle search [<query>]
+
+# Inspect the exact component set a bundle will add (equals what install does)
+specify bundle info <bundle-id>
+
+# Install a bundle's full component set in one operation
+specify bundle install <bundle-id>
+
+# See what's installed, then update or remove non-destructively
+specify bundle list
+specify bundle update <bundle-id>     # or --all
+specify bundle remove <bundle-id>     # removes only this bundle's components
+```
+
+Bundles resolve from a **priority-ordered catalog stack** (project > user >
+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:
+
+```bash
+specify bundle validate --path ./my-bundle      # structural + reference checks
+specify bundle build --path ./my-bundle         # produce a versioned .zip artifact
+```
+
+Four ready-to-read example manifests live under
+[`examples/bundles/`](examples/bundles/) (product manager, business analyst,
+security researcher, developer).
+
+Key guarantees: `info` shows exactly what `install` adds (transparency);
+installs are idempotent and confined to the project root; `remove` never touches
+components another installed bundle still needs; and all consume/author commands
+work **offline** against local or pinned sources.
+
 ### When to Use Which
 
 | Goal | Use |
@@ -257,6 +308,7 @@ See the [Presets reference](https://github.github.io/spec-kit/reference/presets.
 | Integrate an external tool or service | Extension |
 | Enforce organizational or regulatory standards | Preset |
 | Ship reusable domain-specific templates | Either — presets for template overrides, extensions for templates bundled with new commands |
+| Provision a complete role-based setup in one command | Bundle |
 
 ## 📚 Core Philosophy
 

{specify_cli-0.11.3 → specify_cli-0.11.4}/README.md

@@ -26,6 +26,7 @@
 - [🤖 Supported AI Coding Agent Integrations](#-supported-ai-coding-agent-integrations)
 - [🔧 Specify CLI Reference](#-specify-cli-reference)
 - [🧩 Making Spec Kit Your Own: Extensions & Presets](#-making-spec-kit-your-own-extensions--presets)
+- [📦 Bundles: Role-Based Setups](#-bundles-role-based-setups)
 - [📚 Core Philosophy](#-core-philosophy)
 - [🌟 Development Phases](#-development-phases)
 - [🎯 Experimental Goals](#-experimental-goals)
@@ -228,6 +229,56 @@ For example, presets could restructure spec templates to require regulatory trac
 
 See the [Presets reference](https://github.github.io/spec-kit/reference/presets.html) for the full command guide, including resolution order and priority stacking.
 
+## 📦 Bundles: Role-Based Setups
+
+Extensions and presets are individual building blocks. A **bundle** packages a
+curated set of them — extensions, presets, steps, and workflows — into a single,
+versioned, role-oriented setup so a whole team persona (product manager, business
+analyst, security researcher, developer, …) can be provisioned with one command.
+
+A bundle is described by a hand-written `bundle.yml` manifest. It pins each
+component to a version and, optionally, targets a specific integration; a bundle
+with no `integration` is **agnostic** and inherits whatever integration the
+project already uses.
+
+```bash
+# Discover bundles in the active catalog stack
+specify bundle search [<query>]
+
+# Inspect the exact component set a bundle will add (equals what install does)
+specify bundle info <bundle-id>
+
+# Install a bundle's full component set in one operation
+specify bundle install <bundle-id>
+
+# See what's installed, then update or remove non-destructively
+specify bundle list
+specify bundle update <bundle-id>     # or --all
+specify bundle remove <bundle-id>     # removes only this bundle's components
+```
+
+Bundles resolve from a **priority-ordered catalog stack** (project > user >
+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:
+
+```bash
+specify bundle validate --path ./my-bundle      # structural + reference checks
+specify bundle build --path ./my-bundle         # produce a versioned .zip artifact
+```
+
+Four ready-to-read example manifests live under
+[`examples/bundles/`](examples/bundles/) (product manager, business analyst,
+security researcher, developer).
+
+Key guarantees: `info` shows exactly what `install` adds (transparency);
+installs are idempotent and confined to the project root; `remove` never touches
+components another installed bundle still needs; and all consume/author commands
+work **offline** against local or pinned sources.
+
 ### When to Use Which
 
 | Goal | Use |
@@ -237,6 +288,7 @@ See the [Presets reference](https://github.github.io/spec-kit/reference/presets.
 | Integrate an external tool or service | Extension |
 | Enforce organizational or regulatory standards | Preset |
 | Ship reusable domain-specific templates | Either — presets for template overrides, extensions for templates bundled with new commands |
+| Provision a complete role-based setup in one command | Bundle |
 
 ## 📚 Core Philosophy
 

{specify_cli-0.11.3 → specify_cli-0.11.4}/docs/community/extensions.md

@@ -128,6 +128,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Superpowers Bridge | Bridges selected Superpowers disciplines into Spec Kit as evidence-first trust gates for agent workflows. | `process` | Read+Write | [superpowers-bridge](https://github.com/RbBtSn0w/spec-kit-extensions/tree/main/superpowers-bridge) |
 | Superpowers Implementation Bridge | Thin orchestrator between Spec Kit (design) and Superpowers (implementation). Cross-agent. | `process` | Read+Write | [speckit-superpowers-bridge](https://github.com/lihan3238/speckit-superpowers-bridge) |
 | Superspec | Bridges spec-kit with obra/superpowers (brainstorming, TDD, subagent, code-review) into a unified, resumable workflow with graceful degradation and session progress tracking | `process` | Read+Write | [superspec](https://github.com/WangX0111/superspec) |
+| Tasks to GitHub Project | Publish and synchronize Spec Kit tasks as cards on a GitHub Project (v2) kanban board, with priority and status sync between spec.md/tasks.md and the board. | `integration` | Read+Write | [spec-kit-tasks-to-project](https://github.com/mancioshell/spec-kit-tasks-to-project) |
 | Team Assign | Assign tasks.md items to human engineers, split into subtasks, and generate a per-engineer workboard | `process` | Read+Write | [spec-kit-team-assign](https://github.com/tarunkumarbhati/spec-kit-team-assign) |
 | Time Machine | Retroactively apply the full SDD workflow to existing codebases — analyse, spec, and ship feature-by-feature | `process` | Read+Write | [spec-kit-time-machine](https://github.com/teeyo/spec-kit-time-machine) |
 | TinySpec | Lightweight single-file workflow for small tasks — skip the heavy multi-step SDD process | `process` | Read+Write | [spec-kit-tinyspec](https://github.com/Quratulain-bilal/spec-kit-tinyspec) |

specify_cli-0.11.4/docs/reference/bundles.md

@@ -0,0 +1,156 @@
+# Bundles
+
+Bundles compose existing Spec Kit components — extensions, presets, workflows, and steps — into a single, versioned, installable unit. Where extensions and presets are primitives, a bundle is a curated stack that declares everything a team or role needs and installs it in one step through each component's own machinery. Bundles add no new runtime behavior of their own: they are a distribution and composition layer over the primitives you already use.
+
+A bundle is described by a `bundle.yml` manifest and is discovered through the same catalog stack as other components. Installing a bundle resolves its declared components against pinned versions, checks for the single cross-bundle conflict point (the active integration), and applies each component idempotently with full provenance tracking so it can be cleanly removed or refreshed later.
+
+## Search Available Bundles
+
+```bash
+specify bundle search [query]
+```
+
+| Option      | Description                  |
+| ----------- | ---------------------------- |
+| `--offline` | Do not access the network    |
+| `--json`    | Emit machine-readable JSON   |
+
+Searches all active catalogs for bundles matching the query. Without a query, lists every available bundle with its version, role, source, and a trust indicator (`verified` for org-curated catalog entries, `community` otherwise) so you can judge trust before installing.
+
+## Bundle Info
+
+```bash
+specify bundle info <bundle_id>
+```
+
+| Option       | Description                       |
+| ------------ | --------------------------------- |
+| `--offline`  | Do not access the network         |
+| `--json`     | Emit machine-readable JSON        |
+
+Shows full metadata for a bundle along with the **fully expanded component set** it installs — every extension, preset, step, and workflow with its pinned version, plus preset priority and strategy. The output also includes a trust indicator (`verified` vs `community`) so you can judge trust before installing. This preview is the same plan `install` applies, so you can see exactly what will be added before committing. Foreseeable overlaps with components already provided by installed bundles are surfaced here as well.
+
+## Install a Bundle
+
+```bash
+specify bundle install <bundle_id | path>
+```
+
+| Option           | Description                                                         |
+| ---------------- | ------------------------------------------------------------------ |
+| `--integration`  | Override the integration used when initializing/installing         |
+| `--offline`      | Do not access the network                                          |
+
+Installs a bundle's full component set through each primitive's machinery. The argument may be a catalog bundle id, or a local path to a built `.zip` artifact, a bundle directory, or a `bundle.yml` file; local sources install directly without consulting the catalog stack.
+
+If the current directory is not yet a Spec Kit project, `install` initializes one first so a fresh checkout reaches a working state in a single command. `--integration` selects the integration when initializing a new project, and confirms the target when a bundle pins a specific integration but the project's active integration can't be determined (missing or unreadable `.specify/integration.json`). It does **not** override an already-initialized project's active integration: if a bundle targets a different integration than the project's, install aborts with no changes. Integration-agnostic bundles inherit the project's active integration. Installation is idempotent — components already present are skipped. On failure, no provenance record is written (a failed install records nothing), and the components installed during that run are removed on a best-effort basis — removal errors are swallowed, so partial on-disk state may remain.
+
+## Update Bundles
+
+```bash
+specify bundle update [<bundle_id>]
+```
+
+| Option       | Description                          |
+| ------------ | ------------------------------------ |
+| `--all`      | Update every installed bundle        |
+| `--offline`  | Do not access the network            |
+
+Re-resolves a bundle and **refreshes** its components through each primitive's update path, bringing already-installed components up to the bundle's newly pinned versions while preserving primitive-level overrides (such as preset priority). Provide a bundle id, or use `--all` to update everything installed.
+
+> **Pin enforcement is install-time only.** Idempotency checks are id-based, not version-aware: a component that is already present is skipped during `install` without comparing its on-disk version to the manifest pin. Version pins are therefore guaranteed to be applied only when the bundler actually installs a component for the first time or refreshes it. Run `specify bundle update` to re-apply every owned component at its pinned version.
+
+## Remove a Bundle
+
+```bash
+specify bundle remove <bundle_id>
+```
+
+Uninstalls only the components this bundle contributed, leaving any component that another installed bundle still needs in place (no collateral removals).
+
+## List Installed Bundles
+
+```bash
+specify bundle list
+```
+
+| Option   | Description                  |
+| -------- | ---------------------------- |
+| `--json` | Emit machine-readable JSON   |
+
+Lists the bundles installed in the project with their versions, component counts, and install timestamps.
+
+## Initialize a Project with a Bundle
+
+```bash
+specify bundle init [<bundle_id>]
+```
+
+| Option           | Description                              |
+| ---------------- | ---------------------------------------- |
+| `--integration`  | Integration override                     |
+| `--offline`      | Do not access the network                |
+
+Ensures the current directory is a Spec Kit project (initializing it idempotently if needed), then optionally installs the given bundle. Useful as an explicit one-step bootstrap for a new checkout.
+
+## Validate a Bundle
+
+```bash
+specify bundle validate
+```
+
+| Option       | Description                                                          |
+| ------------ | ------------------------------------------------------------------- |
+| `--path`     | Bundle directory or `bundle.yml` (default: current directory)       |
+| `--offline`  | Verify references against bundled/installed components only          |
+
+Reports whether a `bundle.yml` is well-formed and whether every declared component reference resolves. References are checked against bundled components, the project's installed components, and — when online — the active catalogs. Validation fails only when a reference is definitively absent everywhere it could be checked: that is, when an active catalog is reachable and confirms the component is missing. References that cannot be verified — because validation is offline, or because a catalog is unreachable — are downgraded to warnings so authoring can continue, rather than failing the run.
+
+## Build a Bundle Artifact
+
+```bash
+specify bundle build
+```
+
+| Option      | Description                                              |
+| ----------- | ------------------------------------------------------- |
+| `--path`    | Bundle directory (default: current directory)           |
+| `--output`  | Output directory for the artifact                       |
+
+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>`.
+
+## Manage Catalog Sources
+
+Bundles are discovered through a priority-ordered stack of catalog sources (project, user, and built-in scopes).
+
+### List the Catalog Stack
+
+```bash
+specify bundle catalog list
+```
+
+Prints the active, priority-ordered catalog stack with each source's scope and install policy.
+
+### Add a Catalog Source
+
+```bash
+specify bundle catalog add <url>
+```
+
+| Option        | Description                                              |
+| ------------- | ------------------------------------------------------- |
+| `--policy`    | `install-allowed` or `discovery-only`                   |
+| `--priority`  | Source priority (lower = higher precedence; default 10) |
+| `--id`        | Explicit source id                                      |
+
+Registers a project-scoped catalog source and persists it.
+
+### Remove a Catalog Source
+
+```bash
+specify bundle catalog remove <id_or_url>
+```
+
+Removes a project-scoped catalog source. Built-in default sources cannot be deleted.
+
+> **Note:** `search` and `info` work anywhere — with no project they fall back to the built-in/user catalog stack. The remaining state-changing commands (`list`, `update`, `remove`, `catalog`) require a project already initialized with `specify init`. `install` and `init` will initialize a project on demand when run in an uninitialized directory.

{specify_cli-0.11.3 → specify_cli-0.11.4}/docs/reference/overview.md

@@ -31,3 +31,9 @@ Presets customize how Spec Kit works — overriding command files, template file
 Workflows automate multi-step Spec-Driven Development processes into repeatable sequences. They chain commands, prompts, shell steps, and human checkpoints together, with support for conditional logic, loops, fan-out/fan-in, and the ability to pause and resume from the exact point of interruption.
 
 [Workflows reference →](workflows.md)
+
+## Bundles
+
+Bundles compose existing extensions, presets, workflows, and steps into a single, versioned, installable unit. Rather than adding new behavior, a bundle curates a stack of primitives — everything a team or role needs — and installs it in one step through each component's own machinery, with version pinning, conflict checks, and provenance tracking for clean updates and removal.
+
+[Bundles reference →](bundles.md)

specify_cli-0.11.4/examples/bundles/business-analyst/README.md

@@ -0,0 +1,22 @@
+# Business Analyst bundle
+
+A role bundle for business analysts working in a Spec-Driven Development flow:
+requirements elicitation, traceability, and acceptance criteria.
+
+## What it installs
+
+- **Extension** `agent-context` — keeps the agent context file in sync.
+- **Preset** `requirements-elicitation` (priority 10, append) — elicitation and
+  analysis command set.
+- **Steps** `capture-requirements`, `trace-acceptance-criteria`.
+- **Workflow** `requirements-to-spec` — turns captured requirements into a spec.
+
+This bundle is **integration-agnostic**: it inherits the project's active
+integration.
+
+## Usage
+
+```bash
+specify bundle validate --path examples/bundles/business-analyst
+specify bundle build --path examples/bundles/business-analyst --output dist/
+```

specify_cli-0.11.4/examples/bundles/business-analyst/bundle.yml

@@ -0,0 +1,33 @@
+schema_version: "1.0"
+
+bundle:
+  id: "business-analyst"
+  name: "Business Analyst"
+  version: "1.0.0"
+  role: "business-analyst"
+  description: "Spec-Driven Development setup for business analysts: requirements elicitation, traceability, and acceptance criteria."
+  author: "spec-kit-examples"
+  license: "MIT"
+
+requires:
+  speckit_version: ">=0.9.0"
+  tools: []
+  mcp: []
+
+provides:
+  extensions:
+    - id: "agent-context"
+      version: "1.0.0"
+  presets:
+    - id: "requirements-elicitation"
+      version: "1.0.0"
+      priority: 10
+      strategy: "append"
+  steps:
+    - id: "capture-requirements"
+    - id: "trace-acceptance-criteria"
+  workflows:
+    - id: "requirements-to-spec"
+      version: "1.0.0"
+
+tags: ["requirements", "traceability", "analysis"]

specify_cli-0.11.4/examples/bundles/developer/README.md

@@ -0,0 +1,22 @@
+# Developer bundle
+
+A role bundle for developers practicing Spec-Driven Development: implementation
+planning, task breakdown, and code review.
+
+## What it installs
+
+- **Extension** `agent-context` — keeps the agent context file in sync.
+- **Preset** `implementation-planning` (priority 10, append) — implementation
+  planning command set.
+- **Steps** `plan-implementation`, `break-down-tasks`.
+- **Workflow** `spec-to-implementation` — drives a spec through to code.
+
+This bundle is **integration-agnostic**: it inherits the project's active
+integration.
+
+## Usage
+
+```bash
+specify bundle validate --path examples/bundles/developer
+specify bundle build --path examples/bundles/developer --output dist/
+```

specify_cli-0.11.4/examples/bundles/developer/bundle.yml

@@ -0,0 +1,33 @@
+schema_version: "1.0"
+
+bundle:
+  id: "developer"
+  name: "Developer"
+  version: "1.0.0"
+  role: "developer"
+  description: "Spec-Driven Development setup for developers: implementation planning, task breakdown, and code review."
+  author: "spec-kit-examples"
+  license: "MIT"
+
+requires:
+  speckit_version: ">=0.9.0"
+  tools: []
+  mcp: []
+
+provides:
+  extensions:
+    - id: "agent-context"
+      version: "1.0.0"
+  presets:
+    - id: "implementation-planning"
+      version: "1.0.0"
+      priority: 10
+      strategy: "append"
+  steps:
+    - id: "plan-implementation"
+    - id: "break-down-tasks"
+  workflows:
+    - id: "spec-to-implementation"
+      version: "1.0.0"
+
+tags: ["development", "implementation", "code-review"]

specify_cli-0.11.4/examples/bundles/product-manager/README.md

@@ -0,0 +1,22 @@
+# Product Manager bundle
+
+A role bundle that prepares a Spec Kit project for product managers driving
+Spec-Driven Development: discovery, specification, and roadmap planning.
+
+## What it installs
+
+- **Extension** `agent-context` — keeps the agent context file in sync.
+- **Preset** `product-discovery` (priority 10, append) — discovery-oriented
+  command set.
+- **Steps** `draft-spec`, `review-spec` — specification authoring steps.
+- **Workflow** `spec-to-roadmap` — turns an approved spec into a roadmap.
+
+This bundle is **integration-agnostic**: it inherits whatever integration the
+project already uses (e.g. `copilot`, `claude`).
+
+## Usage
+
+```bash
+specify bundle validate --path examples/bundles/product-manager
+specify bundle build --path examples/bundles/product-manager --output dist/
+```

specify_cli-0.11.4/examples/bundles/product-manager/bundle.yml

@@ -0,0 +1,35 @@
+schema_version: "1.0"
+
+bundle:
+  id: "product-manager"
+  name: "Product Manager"
+  version: "1.0.0"
+  role: "product-manager"
+  description: "Spec-Driven Development setup for product managers: discovery, specification, and roadmap workflows."
+  author: "spec-kit-examples"
+  license: "MIT"
+
+requires:
+  speckit_version: ">=0.9.0"
+  tools: []
+  mcp: []
+
+# Agnostic bundle: inherits the project's active integration.
+
+provides:
+  extensions:
+    - id: "agent-context"
+      version: "1.0.0"
+  presets:
+    - id: "product-discovery"
+      version: "1.0.0"
+      priority: 10
+      strategy: "append"
+  steps:
+    - id: "draft-spec"
+    - id: "review-spec"
+  workflows:
+    - id: "spec-to-roadmap"
+      version: "1.0.0"
+
+tags: ["product", "discovery", "roadmap"]