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

{specify_cli-0.13.3 → specify_cli-0.13.4}/.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.13.4}/.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.13.4}/.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.13.4}/.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.13.4}/CHANGELOG.md

@@ -2,6 +2,31 @@
 
 <!-- insert new changelog below this comment -->
 
+## [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.13.4}/PKG-INFO

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

{specify_cli-0.13.3 → specify_cli-0.13.4}/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.13.4}/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.13.4/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.13.4}/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.13.4}/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.13.4}/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`         |                                                                                                                                           |

{specify_cli-0.13.3 → specify_cli-0.13.4}/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

{specify_cli-0.13.3 → specify_cli-0.13.4}/docs/upgrade.md

@@ -12,7 +12,7 @@
 | **CLI Tool — pin a version** | `specify self upgrade --tag vX.Y.Z[suffix]` | Upgrade to a specific release tag instead of the latest stable. Suffixes are limited to dev, alpha/beta/rc, and/or build metadata forms. |
 | **CLI Tool — manual fallback** | `uv tool install specify-cli --force --from git+https://github.com/github/spec-kit.git@vX.Y.Z` | When `specify self upgrade` isn't available (older installs) or when you want explicit control. |
 | **CLI Tool — manual fallback (pipx)** | `pipx install --force git+https://github.com/github/spec-kit.git@vX.Y.Z` | Same as above, for pipx installs. |
-| **Project Files** | `specify init --here --force --integration <your-agent>` | Update slash commands, templates, and scripts in your project |
+| **Project Files** | Run `specify integration upgrade <key>`, then `specify extension update` | Refresh installed integration files and extensions in your project |
 | **Both** | Run CLI upgrade, then project update | Recommended for major version updates |
 
 ---
@@ -89,91 +89,94 @@ specify self check
 
 ## Part 2: Updating Project Files
 
-When Spec Kit releases new features (like new slash commands or updated templates), you need to refresh your project's Spec Kit files.
+When Spec Kit releases new features (like new slash commands, updated templates, or extension changes), you need to refresh the Spec Kit files that were installed into your project.
 
 ### What gets updated?
 
-Running `specify init --here --force` will update:
+For existing Spec Kit projects, use the manifest-aware upgrade path first:
 
-- ✅ **Slash command files** (`.claude/commands/`, `.github/prompts/`, etc.)
-- ✅ **Script files** (`.specify/scripts/`) — **only with `--force`**; without it, only missing files are added
-- ✅ **Template files** (`.specify/templates/`) — **only with `--force`**; without it, only missing files are added
-- ✅ **Shared memory files** (`.specify/memory/`) - **⚠️ See warnings below**
+- ✅ **Integration command/skill files** (`.claude/skills/`, `.github/prompts/`, `.agents/skills/`, etc.)
+- ✅ **Managed shared scripts and templates** (`.specify/scripts/`, `.specify/templates/`) when they are unchanged from the previous managed copy
+- ✅ **Installed extensions** when you run `specify extension update`
+
+The integration upgrade command uses the install manifest to detect local edits. If a managed integration file was modified after install, the command stops and asks you to inspect the change or rerun with `--force`.
 
 ### What stays safe?
 
-These files are **never touched** by the upgrade—the template packages don't even contain them:
+These files are **never touched** by the manifest-aware integration/extension upgrade path:
 
 - ✅ **Your specifications** (`specs/001-my-feature/spec.md`, etc.) - **CONFIRMED SAFE**
 - ✅ **Your implementation plans** (`specs/001-my-feature/plan.md`, `tasks.md`, etc.) - **CONFIRMED SAFE**
+- ✅ **Your constitution** (`.specify/memory/constitution.md`) when using `specify integration upgrade`
 - ✅ **Your source code** - **CONFIRMED SAFE**
 - ✅ **Your git history** - **CONFIRMED SAFE**
 
 The `specs/` directory is completely excluded from template packages and will never be modified during upgrades.
 
-### Update command
+### 1. Check installed integrations
 
 Run this inside your project directory:
 
 ```bash
-specify init --here --force --integration <your-agent>
+specify integration status
 ```
 
-Replace `<your-agent>` with your AI coding agent. Refer to this list of [Supported AI Coding Agent Integrations](reference/integrations.md)
+This reports the default integration, all installed integrations, and any modified or missing managed files. You can also inspect `.specify/integration.json`; installed integrations are listed under `installed_integrations`.
 
-**Example:**
+### 2. Upgrade each installed integration
+
+Run this inside your project directory:
 
 ```bash
-specify init --here --force --integration copilot
+specify integration upgrade <key>
 ```
 
-### Understanding the `--force` flag
+Replace `<key>` with an installed integration key such as `copilot`, `claude`, or `codex`. In projects with multiple installed integrations, run the command once per installed key.
 
-Without `--force`, the CLI warns you and asks for confirmation:
+**Example:**
 
-```text
-Warning: Current directory is not empty (25 items)
-Template files will be merged with existing content and may overwrite existing files
-Proceed? [y/N]
+```bash
+specify integration upgrade claude
+specify integration upgrade codex
 ```
 
-With `--force`, it skips the confirmation and proceeds immediately. It also **overwrites shared infrastructure files** (`.specify/scripts/` and `.specify/templates/`) with the latest versions from the installed Spec Kit release.
+See the [integration reference](reference/integrations.md#upgrade-an-integration) for options such as `--script`, `--integration-options`, and `--force`.
 
-Without `--force`, shared infrastructure files that already exist are skipped — the CLI will print a warning listing the skipped files so you know which ones were not updated.
+### 3. Update installed extensions
 
-**Important: Your `specs/` directory is always safe.** The `--force` flag only affects template files (commands, scripts, templates, memory). Your feature specifications, plans, and tasks in `specs/` are never included in upgrade packages and cannot be overwritten.
-
----
+Run:
 
-## ⚠️ Important Warnings
+```bash
+specify extension update
+```
 
-### 1. Constitution file will be overwritten
+With no extension argument, this updates all installed extensions. Use `specify extension update <extension-id-or-name>` to update only one extension. See the [extensions reference](reference/extensions.md#update-extensions) for details.
 
-**Known issue:** `specify init --here --force` currently overwrites `.specify/memory/constitution.md` with the default template, erasing any customizations you made.
+### Fallback: re-run init
 
-**Workaround:**
+If a project predates manifests, has missing integration metadata, or needs a broader recovery, you can still re-run init:
 
 ```bash
-# 1. Back up your constitution before upgrading
-cp .specify/memory/constitution.md .specify/memory/constitution-backup.md
+specify init --here --force --integration <your-agent>
+```
 
-# 2. Run the upgrade
-specify init --here --force --integration copilot
+Use this as an escape hatch rather than the default project-file upgrade path. It refreshes the selected integration and shared project scaffolding, but it does not use the same per-integration manifest checks before overwriting files.
 
-# 3. Restore your customized constitution
-mv .specify/memory/constitution-backup.md .specify/memory/constitution.md
-```
+## ⚠️ Important Warnings
 
-Or use git to restore it:
+### 1. Constitution file and memory customizations
 
-```bash
-# After upgrade, restore from git history
-git restore .specify/memory/constitution.md
-```
+`specify integration upgrade <key>` does not update `.specify/memory/constitution.md`.
+
+The fallback `specify init --here --force --integration <your-agent>` path also preserves an existing `.specify/memory/constitution.md`; if the file is missing, init creates it from the current constitution template. You do not need a constitution backup/restore step for the manifest-aware upgrade path.
 
-### 2. Custom script or template modifications
+As with any broad fallback refresh, commit or back up local customizations before using `init --here --force` so you can review the resulting diff.
 
-If you customized files in `.specify/scripts/` or `.specify/templates/`, the `--force` flag will overwrite them. Back them up first:
+### 2. Custom integration, script, or template modifications
+
+`specify integration upgrade <key>` blocks when manifest-tracked integration files were modified locally, unless you pass `--force`.
+
+Shared scripts and templates are refreshed when they still match the previously recorded managed copy. Local customizations are preserved unless you explicitly use a force/refresh option that overwrites them. If you customized files in `.specify/scripts/` or `.specify/templates/`, commit or back them up first:
 
 ```bash
 # Back up custom templates and scripts
@@ -215,29 +218,29 @@ Restart your IDE to refresh the command list.
 # Upgrade CLI (auto-detects uv tool vs pipx install)
 specify self upgrade
 
-# Update project files to get new commands
-specify init --here --force --integration copilot
+# Inspect installed integrations
+specify integration status
 
-# Restore your constitution if customized
-git restore .specify/memory/constitution.md
+# Update project files to get new commands
+specify integration upgrade <key>
+specify extension update
 ```
 
 ### Scenario 2: "I customized templates and constitution"
 
 ```bash
-# 1. Back up customizations
-cp .specify/memory/constitution.md /tmp/constitution-backup.md
+# 1. Commit or back up customizations
+git status
 cp -r .specify/templates /tmp/templates-backup
 
 # 2. Upgrade CLI
 specify self upgrade
 
-# 3. Update project
-specify init --here --force --integration copilot
+# 3. Use the manifest-aware project update first
+specify integration upgrade <key>
+specify extension update
 
-# 4. Restore customizations
-mv /tmp/constitution-backup.md .specify/memory/constitution.md
-# Manually merge template changes if needed
+# 4. If the upgrade reports modified managed files, inspect the diff before using --force
 ```
 
 ### Scenario 3: "I see duplicate slash commands in my IDE"
@@ -262,14 +265,14 @@ rm speckit.old-command-name.md
 The git extension is now opt-in, so upgrades do not install it unless you add it explicitly.
 
 ```bash
-# Manually back up files you customized
-cp .specify/memory/constitution.md .specify/memory/constitution.backup.md
+# Upgrade CLI
+specify self upgrade
 
-# Run upgrade
-specify init --here --force --integration copilot
+# Refresh integration files and installed extensions
+specify integration upgrade <key>
+specify extension update
 
-# Restore customizations
-mv .specify/memory/constitution.backup.md .specify/memory/constitution.md
+# The git extension is not added unless you run `specify extension add git`
 ```
 
 If you later decide you want the git extension's commands and hooks, install it explicitly:
@@ -315,19 +318,21 @@ Alternatively, run the `/speckit.specify` command which creates `.specify/featur
    - Codex requires `CODEX_HOME` environment variable
    - Some agents need workspace restart or cache clearing
 
-### "I lost my constitution customizations"
+### "Will init overwrite my constitution customizations?"
+
+Current `specify init --here --force` preserves an existing `.specify/memory/constitution.md`; it creates the file from the template only when it is missing.
 
-**Fix:** Restore from git or backup:
+If you previously lost constitution changes through an older workflow or manual replacement, restore from git or backup:
 
 ```bash
-# If you committed before upgrading
+# If you committed the customized constitution
 git restore .specify/memory/constitution.md
 
 # If you backed up manually
 cp /tmp/constitution-backup.md .specify/memory/constitution.md
 ```
 
-**Prevention:** Always commit or back up `constitution.md` before upgrading.
+**Prevention:** Use `specify integration upgrade <key>` for routine project-file updates. If you need the fallback `specify init --here --force` path, commit first so you can review the full diff afterward.
 
 ### "Warning: Current directory is not empty"
 
@@ -354,7 +359,7 @@ Only Spec Kit infrastructure files:
 - Agent command files (`.claude/commands/`, `.github/prompts/`, etc.)
 - Scripts in `.specify/scripts/`
 - Templates in `.specify/templates/`
-- Memory files in `.specify/memory/` (including constitution)
+- Missing memory files such as `.specify/memory/constitution.md` may be created from templates; an existing constitution is preserved
 
 **What stays untouched:**
 
@@ -365,7 +370,7 @@ Only Spec Kit infrastructure files:
 
 **How to respond:**
 
-- **Type `y` and press Enter** - Proceed with the merge (recommended if upgrading)
+- **Type `y` and press Enter** - Proceed with the merge when using the fallback init path
 - **Type `n` and press Enter** - Cancel the operation
 - **Use `--force` flag** - Skip this confirmation entirely:
 
@@ -375,11 +380,11 @@ Only Spec Kit infrastructure files:
 
 **When you see this warning:**
 
-- ✅ **Expected** when upgrading an existing Spec Kit project
+- ✅ **Expected** when using the fallback init path in an existing Spec Kit project
 - ✅ **Expected** when adding Spec Kit to an existing codebase
 - ⚠️ **Unexpected** if you thought you were creating a new project in an empty directory
 
-**Prevention tip:** Before upgrading, commit or back up your `.specify/memory/constitution.md` if you customized it.
+**Prevention tip:** Before using the fallback init path, commit your current work so any refreshed files are easy to review or restore.
 
 ### "CLI upgrade doesn't seem to work"
 
@@ -418,14 +423,15 @@ uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
 
 ### "Do I need to run specify every time I open my project?"
 
-**Short answer:** No, you only run `specify init` once per project (or when upgrading).
+**Short answer:** No, you only run `specify init` once per project, or later as a fallback recovery path.
 
 **Explanation:**
 
 The `specify` CLI tool is used for:
 
 - **Initial setup:** `specify init` to bootstrap Spec Kit in your project
-- **Upgrades:** `specify init --here --force` to update templates and commands
+- **Routine project-file upgrades:** `specify integration upgrade <key>` and `specify extension update`
+- **Fallback recovery:** `specify init --here --force` when integration metadata is missing or the manifest-aware path cannot be used
 - **Diagnostics:** `specify check` to verify tool installation
 
 Once you've run `specify init`, the slash commands (like `/speckit.specify`, `/speckit.plan`, etc.) are **permanently installed** in your project's agent folder (`.claude/`, `.github/prompts/`, `.pi/prompts/`, `.omp/commands/`, etc.). Your AI coding agent reads these command files directly—no need to run `specify` again.