specify-cli 0.13.3__tar.gz → 0.14.0__tar.gz

{specify_cli-0.13.3 → specify_cli-0.14.0}/.devcontainer/devcontainer.json

@@ -65,7 +65,8 @@
 		},
 		"chat.tools.terminal.autoApprove": {
 			".specify/scripts/bash/": true,
-			".specify/scripts/powershell/": true
+			".specify/scripts/powershell/": true,
+			".specify/scripts/python/": true
 		}
       }
     }

{specify_cli-0.13.3 → specify_cli-0.14.0}/.devcontainer/post-create.sh

@@ -97,6 +97,17 @@ echo -e "\n🤖 Installing CodeBuddy CLI..."
 run_command "npm install -g @tencent-ai/codebuddy-code@latest"
 echo "✅ Done"
 
+echo -e "\n🤖 Installing Factory Droid CLI..."
+run_command "npm install -g droid@latest"
+
+if ! command -v droid >/dev/null 2>&1; then
+  echo -e "\033[0;31m[ERROR] Droid CLI installation did not create 'droid' in PATH.\033[0m" >&2
+  exit 1
+fi
+
+run_command "droid --version > /dev/null"
+echo "✅ Done"
+
 # Installing UV (Python package manager)
 echo -e "\n🐍 Installing UV - Python Package Manager..."
 run_command "pipx install uv"

{specify_cli-0.13.3 → specify_cli-0.14.0}/.github/ISSUE_TEMPLATE/agent_request.yml

@@ -8,7 +8,7 @@ body:
       value: |
         Thanks for requesting a new agent! Before submitting, please check if the agent is already supported.
 
-        **Currently supported agents**: Amp, Antigravity, Auggie CLI, Claude Code, Cline, CodeBuddy, Codex CLI, Cursor, Devin for Terminal, Firebender, Forge, Gemini CLI, GitHub Copilot, Goose, Grok Build, Hermes Agent, IBM Bob, Junie, Kilo Code, Kimi Code, Kiro CLI, Lingma, Mistral Vibe, Oh My Pi, opencode, Pi Coding Agent, Qoder CLI, Qwen Code, RovoDev ACLI, SHAI, Tabnine CLI, Trae, ZCode, Zed
+        **Currently supported agents**: Amp, Antigravity, Auggie CLI, Claude Code, Cline, CodeBuddy, Codex CLI, Cursor, Devin for Terminal, Factory Droid, Firebender, Forge, Gemini CLI, GitHub Copilot, Goose, Grok Build, Hermes Agent, IBM Bob, Junie, Kilo Code, Kimi Code, Kiro CLI, Lingma, Mistral Vibe, Oh My Pi, opencode, Pi Coding Agent, Qoder CLI, Qwen Code, RovoDev ACLI, SHAI, Tabnine CLI, Trae, ZCode, Zed
 
   - type: input
     id: agent-name

{specify_cli-0.13.3 → specify_cli-0.14.0}/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -71,6 +71,7 @@ body:
         - Codex CLI
         - Cursor
         - Devin for Terminal
+        - Factory Droid
         - Firebender
         - Forge
         - Gemini CLI

{specify_cli-0.13.3 → specify_cli-0.14.0}/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -65,6 +65,7 @@ body:
         - Codex CLI
         - Cursor
         - Devin for Terminal
+        - Factory Droid
         - Firebender
         - Forge
         - Gemini CLI

{specify_cli-0.13.3 → specify_cli-0.14.0}/AGENTS.md

@@ -187,7 +187,7 @@ context_markers:
   end: "<!-- SPECKIT END -->"
 ```
 
-- 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.
+- 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`, `.ps1`, and `extensions/agent-context/scripts/python/update_agent_context.py`). 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.
 
 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.
@@ -268,6 +268,25 @@ echo "✅ Done"
 
 ## Command File Formats
 
+### Script References (`scripts:` frontmatter)
+
+Core command templates (`templates/commands/*.md`) that invoke a helper script declare it in a `scripts:` frontmatter block with one line per supported script type. The `{SCRIPT}` placeholder in the command body is replaced at install time with the entry matching the project's selected script type (`--script sh|ps|py`):
+
+```yaml
+scripts:
+  sh: scripts/bash/setup-plan.sh --json
+  ps: scripts/powershell/setup-plan.ps1 -Json
+  py: scripts/python/setup_plan.py --json
+```
+
+| Key  | Script type            | Location                   |
+| ---- | ---------------------- | -------------------------- |
+| `sh` | POSIX shell (bash/zsh) | `scripts/bash/*.sh`        |
+| `ps` | PowerShell             | `scripts/powershell/*.ps1` |
+| `py` | Python                 | `scripts/python/*.py`      |
+
+All three entries must be present and behaviorally equivalent — agents parse the same stdout contract (`FEATURE_DIR:…`, `AVAILABLE_DOCS:…`, `--json` shapes) regardless of which one runs. (The bundled `agent-context` and `git` extension command templates also invoke helpers but do not yet use `scripts:` frontmatter — see [Script Types and Migration](#script-types-and-migration).)
+
 ### Markdown Format
 
 **Standard format:**
@@ -328,9 +347,29 @@ Different agents use different argument placeholders. The placeholder used in co
 - **TOML-based**: `{{args}}` (e.g., Gemini)
 - **YAML-based**: `{{args}}` (e.g., Goose)
 - **Custom**: some agents override the default (e.g., Forge uses `{{parameters}}`)
-- **Script placeholders**: `{SCRIPT}` (replaced with actual script path)
+- **Script placeholders**: `{SCRIPT}` (replaced with the resolved command from the template's `scripts:` frontmatter, per the project's `--script sh|ps|py` selection)
 - **Agent placeholders**: `__AGENT__` (replaced with agent name)
 
+## Script Types and Migration
+
+Spec Kit ships every core workflow script in three interchangeable variants — POSIX shell (`sh`), PowerShell (`ps`), and Python (`py`) — selected per project with `specify init --script sh|ps|py`. Each core command template that invokes a helper script carries all three in its `scripts:` frontmatter (templates that don't call a script, e.g. `constitution`/`specify`, have no `scripts:` block); see [Script References](#script-references-scripts-frontmatter).
+
+### Why Python is recommended
+
+- **No extra runtime.** The `specify` CLI is already Python, so the interpreter is guaranteed present — `py` adds no new dependency.
+- **Path toward a single source of truth.** The shell variants require paired `.sh` + `.ps1` maintenance and diverge on JSON handling (`jq` vs manual parsing). The Python variant avoids `jq` and is intended to eventually replace that dual-maintenance — but that consolidation has not happened yet: all three variants are still maintained in parallel (see the parity rule below).
+- **Parity-tested.** The Python ports are covered by tests — output-parity tests against the shell scripts where the contract is stdout-based, and direct unit tests elsewhere — so the stdout contract agents rely on stays stable.
+
+### Defaults and availability
+
+- `py` is available today for the core command templates (via their `scripts:` frontmatter). The bundled extensions (`agent-context`, `git`) ship Python script variants on disk, but their command templates still hard-code the Bash/PowerShell invocations, so `--script py` does not yet route those extension commands to Python — wiring `py` into the extension command templates is tracked separately.
+- Selection is per project: interactive `specify init` prompts for the script type, while non-interactive runs default to a shell variant by OS (`sh` on Linux/macOS, `ps` on Windows). `py` is chosen at the prompt or via `--script py`.
+- `sh` and `ps` remain fully supported. Nothing is removed, and `py` is not yet the default.
+
+### Parity rule for contributors
+
+All three script types are first-class: any change to a workflow script must update `sh`, `ps`, and `py` together and keep their tests (parity and unit) green. Making `py` the default and eventually retiring `sh`/`ps` is future work gated on adoption, tracked under the script-unification epic ([#3277](https://github.com/github/spec-kit/issues/3277)) — not something to act on from this doc.
+
 ## Special Processing Requirements
 
 Some agents require custom processing beyond the standard template transformations:

{specify_cli-0.13.3 → specify_cli-0.14.0}/CHANGELOG.md

@@ -2,6 +2,56 @@
 
 <!-- insert new changelog below this comment -->
 
+## [0.14.0] - 2026-07-23
+
+### Changed
+
+- docs: add spec-kit-copilot to community friends (#3675)
+- fix(integrations): recompute invoke_separator from retained parsed_options (#3664)
+- fix(workflows): preserve intra-overlay order for multiple insert_after edits (#3662)
+- fix(bundler): reject falsy non-mapping requires/provides in manifest from_dict (#3661)
+- fix(bundler): dump_yaml writes literal UTF-8 (allow_unicode=True) (#3660)
+- fix(integrations): declare kiro-cli multi-install safe (#3477)
+- fix(git-extension): trim trailing whitespace before stripping commit-message quotes (#3673)
+- fix(bundler): order bundle members by canonical POSIX arcname (reproducible builds) (#3658)
+- fix(integrations): Cline overrides post_process_command_content (correct hook name) (#3657)
+- docs(workflows): gate step docstring lists the 'retry' on_reject behaviour (#3656)
+- fix: harden bounded reads and redirect validation (#3671)
+- fix(packaging): bundle scripts/python into the wheel core_pack (#3665) (#3670)
+- fix: bundle scripts/python in wheel so --script py works (#3665) (#3668)
+- docs(workflows): init step docstring lists the 'py' script type (#3655)
+- fix(integrations): declare LingmaIntegration multi_install_safe (#3654)
+- fix: guard constitution command against feature execution (#3646)
+- Fix duplicate step numbering in specify command (#3647)
+- docs(scripts): document the 'py' script type and sh/ps migration plan (#3284) (#3653)
+- harden: bound HTTP reads and enforce strict redirects (#3140)
+- chore: release 0.13.4, begin 0.13.5.dev0 development (#3649)
+
+## [0.13.4] - 2026-07-22
+
+### Changed
+
+- docs(concepts): document the spec-of-specs feature breakdown approach (#3648)
+- fix(scripts): git-ext PowerShell emits the '# To persist' SPECIFY_FEATURE hint (parity) (#3632)
+- fix(integrations): validate cached catalog shape before returning it (#3627)
+- fix(bundler): reject non-list 'catalogs' in bundle-catalogs.yml with a clean error (#3623)
+- fix(bundler): guard lazy .hostname ValueError in catalog add_source (#3644)
+- Add Intake Authoring Governance preset to community catalog (#3643)
+- feat: add Factory Droid CLI integration (#822) (#3587)
+- docs(installation): document the 'py' (Python) script type (#3640)
+- fix(init): show hyphenated /speckit-<name> in Next Steps for Forge projects (#3642)
+- fix(extensions): render hyphenated hook invocations for Forge projects (#3641)
+- fix(workflows): workflow add detects local YAML files case-insensitively (#3633)
+- fix(workflows): list-literal expression ignores trailing/empty commas (#3631)
+- fix(workflows): StepRegistry.add tolerates a corrupted non-dict existing entry (#3630)
+- fix(bundler): reject non-mapping 'integration' in a bundle manifest (#3629)
+- fix(workflows): command/prompt steps fail cleanly on a non-string integration (#3626)
+- docs(core): document the 'py' (Python) --script type in the init option table (#3625)
+- fix(workflows): gate prompt uses isdecimal() so a superscript digit doesn't crash (#3624)
+- fix(integrations): Cline dispatches hyphenated /speckit-<cmd> invocations (#3622)
+- docs(upgrade): document integration upgrade / extension update as the project-files upgrade path (#3326)
+- chore: release 0.13.3, begin 0.13.4.dev0 development (#3645)
+
 ## [0.13.3] - 2026-07-22
 
 ### Changed

{specify_cli-0.13.3 → specify_cli-0.14.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: specify-cli
-Version: 0.13.3
+Version: 0.14.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

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/community/friends.md

@@ -1,7 +1,7 @@
 # Community Friends
 
 > [!NOTE]
-> Community projects listed here are independently created and maintained by their respective authors. They are **not reviewed, nor endorsed, nor supported by GitHub**. Review their source code before installation and use at your own discretion.
+> Community projects listed here are independently created and maintained by their respective authors. Unless explicitly marked as a **first-party GitHub project**, they are **not reviewed, nor endorsed, nor supported by GitHub**. Review their source code before installation and use at your own discretion.
 
 Community projects that extend, visualize, or build on Spec Kit:
 
@@ -16,3 +16,5 @@ Community projects that extend, visualize, or build on Spec Kit:
 - **[cc-spec-kit](https://github.com/speckit-community/cc-spec-kit)** — Community-maintained plugin for Claude Code and GitHub Copilot CLI that installs Spec Kit skills via the plugin marketplace.
 
 - **[spectatui](https://github.com/tinesoft/spectatui)** — A terminal UI (TUI) dashboard for Spec Kit that lets you track features, manage specifications, integrations, presets, workflows, and extensions, and monitor AI agent workflows. Attach to existing AI sessions or launch new ones from your terminal. Keyboard and mouse support. Light/dark theme support. Customizable and performance-oriented. Requires the `specify` CLI in your PATH.
+
+- **[spec-kit-copilot](https://github.com/github/spec-kit-copilot)** — _First-party GitHub project._ A GitHub Copilot **skills plugin** that exposes the Spec Kit `specify` CLI to the Copilot agent in both the Copilot CLI and the GitHub Copilot app. It provides a focused skill per `specify` command group — setup, init, check, extensions, presets, bundles, workflows, workflow steps, and self-upgrade — so you can navigate and drive the entire Spec Kit ecosystem through natural language, letting Copilot decide when and how to run the right `specify` commands on your behalf.

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/community/presets.md

@@ -19,6 +19,7 @@ The following community-contributed presets customize how Spec Kit behaves — o
 | Explicit Task Dependencies | Adds explicit `(depends on T###)` dependency declarations and an Execution Wave DAG to tasks.md for parallel scheduling | 1 template, 1 command | — | [spec-kit-preset-explicit-task-dependencies](https://github.com/Quratulain-bilal/spec-kit-preset-explicit-task-dependencies) |
 | Fiction Book Writing | It adapts the Spec-Driven Development workflow for storytelling to create books or audiobooks (with annotations) in 12 languages: features become story elements, specs become story briefs, plans become story structures, and tasks become scene-by-scene writing tasks. Supports single and multi-POV, all major plot structure frameworks, and two style modes: an author voice sample or humanized AI prose principles. Supports interactive elements like brainstorming, interview, roleplay, and extras like statistics, cover builder, illustration builder, and bio command. Export with templates for KDP, D2D, etc. | 26 templates, 34 commands, 2 scripts | — | [speckit-preset-fiction-book-writing](https://github.com/adaumann/speckit-preset-fiction-book-writing) |
 | Game Narrative Writing | Preset for game narrative design and interactive storytelling. It adapts the Spec-Driven Development workflow for game narratives: features become story mechanics, specs become narrative briefs, plans become story maps, and tasks become dialogue and scene-writing tasks. Supports branching narratives, player agency systems, state machines, and interactive dialogue trees. | 37 templates, 34 commands, 5 scripts | — | [speckit-preset-game-narrative-writing](https://github.com/adaumann/speckit-preset-game-narrative-writing) |
+| Intake Authoring Governance | Creates traceable Spec Kit intake files and receipts from ordered text sources while preserving clarification, update, and delivery-authority boundaries. | 7 templates, 2 commands, 2 scripts | — | [spec-kit-preset-intake-authoring-governance](https://github.com/hindermath/spec-kit-preset-intake-authoring-governance) |
 | Intake Review Governance | Adds hash-bound review, repair, and status gates for single, series, and campaign intake files before interactive, autonomous, or parallel Spec Kit execution. | 8 templates, 3 commands, 2 scripts | — | [spec-kit-preset-intake-review-governance](https://github.com/hindermath/spec-kit-preset-intake-review-governance) |
 | iSAQB Architecture Governance | Adds general iSAQB/CPSA-F and arc42 software-architecture governance, including audit-ready Spec Kit run evidence for architecture goals, views, quality scenarios, ADRs, risks, and technical debt. | 13 templates, 3 commands | — | [spec-kit-preset-isaqb-architecture-governance](https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance) |
 | Jira Issue Tracking | Overrides `speckit.taskstoissues` to create Jira epics, stories, and tasks instead of GitHub Issues via Atlassian MCP tools | 1 command | — | [spec-kit-preset-jira](https://github.com/luno/spec-kit-preset-jira) |

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/concepts/complex-features.md

@@ -63,10 +63,14 @@ independently specified sub-features. Each sub-feature gets its own
 `spec.md`, `plan.md`, and `tasks.md`, and runs through its own
 specify/plan/tasks/implement cycle.
 
-This is the "spec of specs" approach: the first iteration breaks a massive
-feature into smaller, self-contained specs that can each be implemented without
-overwhelming the model. It adds the most overhead, so reserve it for features
-that are too large to handle any other way.
+This is the "spec of specs" approach: a first pass breaks a massive feature into
+smaller, self-contained specs that can each be implemented without overwhelming the
+model. It adds the most overhead, so reserve it for features that are too large to
+handle any other way.
+
+See [Spec of Specs](spec-of-specs.md) for the full procedure — how to run the
+roadmap pass, structure the roadmap artifact, link sub-specs back to it, and a worked
+example.
 
 ## Which Approach to Choose
 

specify_cli-0.14.0/docs/concepts/spec-of-specs.md

@@ -0,0 +1,171 @@
+# Spec of Specs
+
+When a feature is too large to run through a single
+`/speckit.specify` → `/speckit.plan` → `/speckit.tasks` → `/speckit.implement`
+cycle without the model losing track mid-implementation, you can break it into a
+**roadmap** of smaller, independently-specified sub-features. This is the "spec of
+specs" approach: one up-front pass decomposes a massive feature into self-contained
+specs, and each of those runs through its own specify/plan/tasks/implement cycle.
+
+> **When to reach for this.** Decomposition adds the most overhead of any strategy
+> in [Handling Complex Features](complex-features.md). Use it **only when the lighter
+> options there are insufficient** — first try limiting how many tasks run per
+> `/speckit.implement` invocation, then sub-agent delegation, then a combination.
+> Reach for a spec of specs only when even a single phase is too large to handle in
+> one run.
+
+The rest of this page describes *how* to do it with the tools you already have. No
+new commands or extensions are required.
+
+## The roadmap pass
+
+Before writing any sub-spec, do a single decomposition pass to produce a roadmap.
+Treat this as a lightweight planning conversation with your agent, not a full spec:
+
+1. **State the whole feature.** Describe the large feature (the "epic") in a
+   sentence or two so the agent has the full picture up front.
+2. **Identify independent slices.** Ask the agent to propose a small set of
+   sub-features that each deliver a coherent piece of the epic and can be specified
+   on their own. Aim for slices that are independently testable — implementing just
+   one should leave you with something demonstrable.
+3. **Draw the boundaries.** For each slice, write one line of intent and an explicit
+   scope boundary (what is in, what is deferred to a sibling slice). Sharp
+   boundaries are what keep each sub-spec small enough to fit in context.
+4. **Order by dependency.** Note which slices depend on others and sequence them so
+   prerequisites come first. Slices with no dependency on each other can be built in
+   any order. To build independent slices in parallel, use separate worktrees so each
+   run has isolated active-feature state.
+5. **Record the result as a roadmap.** Capture the slices in a durable roadmap file
+   (below) so every later sub-spec can point back to it.
+
+The roadmap is deliberately shallow: it names and orders the sub-features but does
+**not** design them. The design happens when each slice runs through its own
+`/speckit.specify`.
+
+## The roadmap artifact
+
+The roadmap is an ordinary Markdown file you author and keep under version control —
+there is no special tooling behind it. Put it where the sub-specs can find it:
+
+- For a feature-scoped epic: `specs/<epic-slug>/roadmap.md`.
+- For a larger, cross-cutting epic: a top-level `ROADMAP.md`.
+
+Each roadmap entry carries a stable id (used later for linking), a name, its intent,
+its scope boundary, its dependencies, a status, and — once the sub-spec exists — a
+link to it. A minimal template:
+
+```markdown
+# Roadmap: <epic name>
+
+<One or two sentences: what the epic is and why it is being decomposed.>
+
+**Status legend**: planned · in-progress · done
+
+| ID | Sub-feature | Intent | Scope boundary | Depends on | Status | Sub-spec |
+|----|-------------|--------|----------------|-----------|--------|----------|
+| R1 | <name>      | <one line> | <in / deferred> | —      | planned | — |
+| R2 | <name>      | <one line> | <in / deferred> | R1     | planned | — |
+| R3 | <name>      | <one line> | <in / deferred> | R1     | planned | — |
+```
+
+Keep the `ID` column immutable once a sub-spec references it — it is the anchor for
+traceability. Fill in the `Sub-spec` column with the path to each sub-feature's spec
+directory as you create it, and update `Status` as work progresses.
+
+## Specifying each sub-feature
+
+With the roadmap in hand, work through the entries one at a time using the normal
+Spec Kit flow — nothing new to learn:
+
+1. Pick the next roadmap entry whose dependencies are already `done` (or have none).
+2. Run `/speckit.specify` for just that slice, describing only its intent and scope
+   from the roadmap entry. Because the slice is bounded, its spec, plan, and tasks
+   stay well within the context window.
+3. Run `/speckit.plan`, `/speckit.tasks`, and `/speckit.implement` for that slice as
+   usual.
+4. Mark the roadmap entry `done` and move to the next one.
+
+Each slice is a complete, independent Spec Kit feature with its own
+`spec.md`/`plan.md`/`tasks.md`. The roadmap is what ties them together.
+
+## Linking sub-specs to the roadmap
+
+To keep scope and intent from drifting across separate runs, every sub-spec
+references its roadmap entry, and the roadmap links back — a simple, greppable,
+bidirectional convention:
+
+- **Sub-spec → roadmap.** In the sub-feature's `spec.md`, name the parent roadmap
+  and entry id in the `Input` / summary line, for example:
+
+  ```markdown
+  **Input**: Parent roadmap: `specs/<epic>/roadmap.md` → entry **R3**. <feature description>
+  ```
+
+- **Roadmap → sub-spec.** In the roadmap table, set the entry's `Sub-spec` column to
+  the sub-feature's directory, e.g. `specs/<epic>-part-3/`.
+
+Because both directions are plain text, you can trace any sub-spec back to its place
+in the epic (and find its siblings) with a quick search — no tooling, no metadata
+schema.
+
+## Keeping the roadmap and sub-specs in sync
+
+The roadmap is a living document. As you learn more, keep it and the sub-specs
+aligned:
+
+- **Roadmap first, then reconcile.** When scope shifts, update the roadmap entry
+  first, then update any sub-specs it affects. The roadmap is the source of truth for
+  how the epic is divided.
+- **Respect dependencies and ordering.** If a slice depends on another, build the
+  prerequisite first and cross-reference the dependent sub-spec so the relationship
+  is visible from both sides.
+- **Recurse when a slice is still too big.** If a sub-feature turns out to be too
+  large to specify in one cycle, give it its own roadmap and decompose it further —
+  the same approach applies one level down. Recursion adds overhead, so only go as
+  deep as the context problem actually requires.
+
+## Worked example
+
+Suppose the epic is **"Add a self-service billing portal"** — far too large for a
+single cycle. The roadmap pass breaks it into three independently-specifiable
+slices.
+
+`specs/billing-portal/roadmap.md`:
+
+```markdown
+# Roadmap: Self-service billing portal
+
+Let customers view invoices, manage payment methods, and change plans without
+contacting support. Too large for one cycle, so it is split into independent slices.
+
+**Status legend**: planned · in-progress · done
+
+| ID | Sub-feature        | Intent                                   | Scope boundary                              | Depends on | Status  | Sub-spec |
+|----|--------------------|------------------------------------------|---------------------------------------------|-----------|---------|----------|
+| R1 | Invoice history    | Customers view and download past invoices | Read-only; no payment actions               | —         | done    | specs/billing-invoices/ |
+| R2 | Payment methods    | Add, remove, and set a default card       | No plan changes; assumes invoices exist     | R1        | in-progress | specs/billing-payment-methods/ |
+| R3 | Plan changes       | Upgrade/downgrade the subscription plan   | Uses R2's default payment method            | R1, R2    | planned | — |
+```
+
+Each slice is then specified on its own. For example, the **R2** sub-feature's
+`spec.md` opens with a back-reference:
+
+```markdown
+# Feature Specification: Billing — payment methods
+
+**Input**: Parent roadmap: `specs/billing-portal/roadmap.md` → entry **R2**.
+Let customers add, remove, and set a default payment method in the billing portal.
+```
+
+From here a reader can trace **R2** back to the roadmap, see that it depends on
+**R1** (invoice history, already `done`), and see that **R3** (plan changes) is
+waiting on it. Building R1, then R2, then R3 keeps every run small while the roadmap
+preserves the shape of the whole epic.
+
+## For automation (optional)
+
+If you would rather automate roadmap capture and consistency checks than maintain
+the file by hand, the community-maintained
+[Spec Roadmap extension](https://github.com/srobroek/speckit-roadmap) explores that
+direction. It is a third-party extension and is not required — the manual convention
+above is enough on its own.

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/installation.md

@@ -77,9 +77,9 @@ specify init <project_name> --integration pi
 specify init <project_name> --integration omp
 ```
 
-### Specify Script Type (Shell vs PowerShell)
+### Specify Script Type (Shell, PowerShell, or Python)
 
-All automation scripts now have both Bash (`.sh`) and PowerShell (`.ps1`) variants.
+Automation scripts are available as Bash (`.sh`), PowerShell (`.ps1`), and Python (`.py`) variants.
 
 Auto behavior:
 
@@ -92,6 +92,7 @@ Force a specific script type:
 ```bash
 specify init <project_name> --script sh
 specify init <project_name> --script ps
+specify init <project_name> --script py
 ```
 
 ### Ignore Agent Tools Check
@@ -131,6 +132,7 @@ Scripts are installed into a variant subdirectory matching the chosen script typ
 
 - `.specify/scripts/bash/` — contains `.sh` scripts (default on Linux/macOS)
 - `.specify/scripts/powershell/` — contains `.ps1` scripts (default on Windows)
+- `.specify/scripts/python/` — contains `.py` scripts (chosen with `--script py`; also installs the platform shell fallback)
 
 ## Troubleshooting
 

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/local-development.md

@@ -2,7 +2,7 @@
 
 This guide shows how to iterate on the `specify` CLI locally without publishing a release or committing to `main` first.
 
-> Scripts now have both Bash (`.sh`) and PowerShell (`.ps1`) variants. The CLI auto-selects based on OS unless you pass `--script sh|ps`.
+> Scripts are available as Bash (`.sh`), PowerShell (`.ps1`), and Python (`.py`) variants. Interactive `specify init` prompts you to choose one; non-interactive runs default to a shell variant for your OS. Pass `--script sh|ps|py` to select explicitly.
 
 ## 1. Clone and Switch Branches
 
@@ -189,7 +189,7 @@ rm -rf .venv dist build *.egg-info
 | `ModuleNotFoundError: typer` | Run `uv pip install -e .` |
 | Scripts not executable (Linux) | Re-run init or `chmod +x scripts/*.sh` |
 | Git commands unavailable | Install the git extension with `specify extension add git` |
-| Wrong script type downloaded | Pass `--script sh` or `--script ps` explicitly |
+| Wrong script type downloaded | Pass `--script sh`, `--script ps`, or `--script py` explicitly |
 | TLS errors on corporate network | Configure your environment's certificate store or proxy. The `--skip-tls` flag is deprecated and has no effect. |
 
 ## 14. Next Steps

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/quickstart.md

@@ -3,7 +3,7 @@
 This guide will help you get started with Spec-Driven Development using Spec Kit. Throughout, we illustrate each step with a running example: **Taskify**, a small team productivity platform.
 
 > [!NOTE]
-> Automation scripts are provided as both Bash (`.sh`) and PowerShell (`.ps1`) variants. The `specify` CLI auto-selects based on your OS unless you pass `--script sh|ps`.
+> Automation scripts are provided as Bash (`.sh`), PowerShell (`.ps1`), and Python (`.py`) variants. Interactive `specify init` prompts you to choose one; non-interactive runs default to a shell variant for your OS. Pass `--script sh|ps|py` to select explicitly.
 
 > [!NOTE]
 > Commands are shown here in `/speckit.*` form, but the exact invocation depends on your agent. Some skills-based agents use `$speckit-*` (e.g. Codex, ZCode) or `/skill:speckit-*` (e.g. Kimi). Use whichever form your agent exposes — the steps are otherwise identical.

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/reference/core.md

@@ -12,7 +12,7 @@ specify init [<project_name>]
 | ------------------------ | ------------------------------------------------------------------------ |
 | `--integration <key>`    | AI coding agent integration to use (e.g. `copilot`, `claude`, `gemini`). See the [Integrations reference](integrations.md) for all available keys |
 | `--integration-options`  | Options for the integration (e.g. `--integration-options="--commands-dir .myagent/cmds"`) |
-| `--script sh\|ps`        | Script type: `sh` (bash/zsh) or `ps` (PowerShell)                       |
+| `--script sh\|ps\|py`    | Script type: `sh` (bash/zsh), `ps` (PowerShell), or `py` (Python)       |
 | `--here`                 | Initialize in the current directory instead of creating a new one        |
 | `--force`                | Force merge/overwrite when initializing in an existing directory         |
 | `--ignore-agent-tools`   | Skip checks for AI coding agent CLI tools                                |

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/reference/integrations.md

@@ -15,6 +15,7 @@ The Specify CLI supports a wide range of AI coding agents. When you run `specify
 | [Codex CLI](https://github.com/openai/codex)                                         | `codex`          | Skills-based integration; installs skills into `.agents/skills` and invokes them as `$speckit-<command>` |
 | [Cursor](https://cursor.sh/)                                                         | `cursor-agent`   |                                                                                                                                           |
 | [Devin for Terminal](https://cli.devin.ai/docs)                                      | `devin`          | Skills-based integration; installs skills into `.devin/skills/` and invokes them as `/speckit-<command>` |
+| [Factory Droid](https://docs.factory.ai/cli/getting-started/overview)               | `droid`          | Skills-based integration; installs skills into `.factory/skills/` and invokes them as `/speckit-<command>`                               |
 | [Firebender](https://firebender.com/)                                                | `firebender`     | IDE-based agent for Android Studio / IntelliJ                                                                                             |
 | [Forge](https://forgecode.dev/)                                                      | `forge`          |                                                                                                                                           |
 | [Gemini CLI](https://github.com/google-gemini/gemini-cli)                            | `gemini`         |                                                                                                                                           |
@@ -85,7 +86,7 @@ specify integration install <key>
 
 | Option                   | Description                                                              |
 | ------------------------ | ------------------------------------------------------------------------ |
-| `--script sh\|ps`        | Script type: `sh` (bash/zsh) or `ps` (PowerShell)                        |
+| `--script sh\|ps\|py`    | Script type: `sh` (bash/zsh), `ps` (PowerShell), or `py` (Python)        |
 | `--force`                | Opt in to installing alongside integrations that are not declared multi-install safe |
 | `--integration-options`  | Integration-specific options (e.g. `--integration-options="--commands-dir .myagent/cmds"`) |
 
@@ -121,7 +122,7 @@ specify integration switch <key>
 
 | Option                   | Description                                                              |
 | ------------------------ | ------------------------------------------------------------------------ |
-| `--script sh\|ps`        | Script type: `sh` (bash/zsh) or `ps` (PowerShell)                        |
+| `--script sh\|ps\|py`    | Script type: `sh` (bash/zsh), `ps` (PowerShell), or `py` (Python)        |
 | `--force`                | Force removal of modified files during uninstall; when the target is already installed, overwrite managed shared templates while changing the default |
 | `--refresh-shared-infra` | Also overwrite shared infrastructure files even if you customized them (otherwise customizations are preserved) |
 | `--integration-options`  | Options for the target integration when it is not already installed      |
@@ -149,7 +150,7 @@ specify integration upgrade [<key>]
 | Option                   | Description                                                              |
 | ------------------------ | ------------------------------------------------------------------------ |
 | `--force`                | Overwrite files even if they have been modified                          |
-| `--script sh\|ps`        | Script type: `sh` (bash/zsh) or `ps` (PowerShell)                        |
+| `--script sh\|ps\|py`    | Script type: `sh` (bash/zsh), `ps` (PowerShell), or `py` (Python)        |
 | `--integration-options`  | Options for the integration                                              |
 
 Reinstalls an installed integration with updated templates and commands (e.g., after upgrading Spec Kit). Defaults to the default integration; if a key is provided, it must be one of the installed integrations. Detects locally modified files and blocks the upgrade unless `--force` is used. Stale files from the previous install that are no longer needed are removed automatically. Shared templates stay aligned with the default integration even when upgrading a non-default integration.
@@ -256,31 +257,30 @@ Spec Kit tracks one default integration in `.specify/integration.json` with `def
 
 An integration is multi-install safe when it uses a static, unique agent root and command directory, stable command invocation settings, and a separate install manifest whose managed files do not overlap another safe integration. Registry tests enforce those path and manifest invariants. Shared Spec Kit templates remain aligned to the single default integration.
 
-The Isolation column below lists paths Spec Kit manages for that integration (skills/commands roots and any integration-owned rule files). It is not a full inventory of every file an agent may read.
-
-**Agent-context defaults are separate.** The optional agent-context extension maps each integration to a default context file in `extensions/agent-context/agent-context-defaults.json`. Those defaults are independent of multi-install safety: several agents may share a root file such as `AGENTS.md` when the extension is enabled. Multi-install safety does not require a unique context file per safe integration.
+The Command directory column below lists the directory each integration installs its commands or skills into. Context-file targeting is a separate concern from integration multi-install safety: `multi_install_safe` is an integration declaration about command/skill paths, whereas the optional agent-context extension manages a per-agent context file (for example `AGENTS.md` or `CLAUDE.md`) and can even synchronize several anchors at once via its `context_files` setting. Multiple agents mapping to the same context file is expected there and does not affect whether an integration is multi-install safe; see the agent-context extension for details.
 
 The currently declared multi-install safe integrations are:
 
-| Key | Isolation |
-| --- | --------- |
-| `auggie` | `.augment/commands`, `.augment/rules/specify-rules.md` |
-| `claude` | `.claude/skills`, `CLAUDE.md` |
-| `cline` | `.clinerules/workflows`, `.clinerules/specify-rules.md` |
-| `codebuddy` | `.codebuddy/commands`, `CODEBUDDY.md` |
-| `codex` | `.agents/skills`, `AGENTS.md` |
-| `cursor-agent` | `.cursor/skills`, `.cursor/rules/specify-rules.mdc` |
-| `firebender` | `.firebender/commands`, `.firebender/rules/specify-rules.mdc` |
-| `gemini` | `.gemini/commands`, `GEMINI.md` |
+| Key | Command directory |
+| --- | ----------------- |
+| `auggie` | `.augment/commands` |
+| `claude` | `.claude/skills` |
+| `cline` | `.clinerules/workflows` |
+| `codebuddy` | `.codebuddy/commands` |
+| `codex` | `.agents/skills` |
+| `cursor-agent` | `.cursor/skills` |
+| `firebender` | `.firebender/commands` |
+| `gemini` | `.gemini/commands` |
 | `grok` | `.grok/skills` |
-| `junie` | `.junie/commands`, `.junie/AGENTS.md` |
-| `kilocode` | `.kilocode/workflows`, `.kilocode/rules/specify-rules.md` |
-| `qodercli` | `.qoder/commands`, `QODER.md` |
-| `qwen` | `.qwen/commands`, `QWEN.md` |
-| `shai` | `.shai/commands`, `SHAI.md` |
-| `tabnine` | `.tabnine/agent/commands`, `TABNINE.md` |
-| `trae` | `.trae/skills`, `.trae/rules/project_rules.md` |
-| `zcode` | `.zcode/skills`, `ZCODE.md` |
+| `junie` | `.junie/commands` |
+| `kilocode` | `.kilocode/workflows` |
+| `kiro-cli` | `.kiro/prompts` |
+| `qodercli` | `.qoder/commands` |
+| `qwen` | `.qwen/commands` |
+| `shai` | `.shai/commands` |
+| `tabnine` | `.tabnine/agent/commands` |
+| `trae` | `.trae/skills` |
+| `zcode` | `.zcode/skills` |
 
 Integrations that share a command directory with another integration, require dynamic install paths such as `--commands-dir`, or merge shared tool settings are not declared safe by default. They can still be installed alongside another integration with `--force`.
 

{specify_cli-0.13.3 → specify_cli-0.14.0}/docs/toc.yml

@@ -55,6 +55,8 @@
       href: concepts/spec-persistence.md
     - name: Handling Complex Features
       href: concepts/complex-features.md
+    - name: Spec of Specs
+      href: concepts/spec-of-specs.md
 
 # Development workflows
 - name: Development