specify-cli 1.0.5__tar.gz → 1.0.6__tar.gz

specify_cli-1.0.6/.github/scripts/check_extension_version_bump.py

@@ -0,0 +1,232 @@
+#!/usr/bin/env python3
+"""Fail a PR that changes bundled extension content without a version bump.
+
+Update offers from `specify extension update` are version-driven: an
+extension is offered (and installed) only when the semver in
+`extensions/catalog.json` exceeds the installed copy's registered
+version. A content change shipped without a version bump is therefore
+never delivered automatically (#4345) — a bump is what makes a change
+actually reach existing installs, and this guard is what makes the bump
+non-optional.
+
+This check enforces two invariants on the extensions listed in
+`extensions/catalog.json`:
+
+1. Any change to a file under `extensions/<id>/` must increase the
+   `version:` in that extension's `extension.yml` (PEP 440 comparison,
+   the same semantics `extension update` uses), and the resulting
+   version must itself parse as PEP 440 — including for a brand-new
+   extension, since the CLI rejects a manifest whose version it cannot
+   parse.
+2. Every `version` in `extensions/catalog.json` must parse as PEP 440
+   (`extension update` skips entries it cannot parse), and for entries
+   with an in-repo directory it must equal a likewise-valid
+   `extension.version` in the manifest (the catalog is what update
+   checks compare against, and the update preflight rejects a manifest
+   whose version differs from the catalog's). This runs over every
+   catalog entry, so catalog-only (hosted) entries and catalog-only
+   promotions of existing directories are covered too.
+
+Usage:
+    check_extension_version_bump.py BASE_REF [HEAD_REF]
+
+BASE_REF is a git ref/SHA for the PR base (must be fetchable with
+`git show`). HEAD_REF defaults to the working tree's HEAD. Exits 0 when
+all invariants hold, 1 otherwise, printing one line per violation.
+
+Extensions under `extensions/` that are not in the catalog (the
+`selftest` fixture and the `template` scaffold) are exempt: no update
+flow is driven by their versions.
+"""
+
+from __future__ import annotations
+
+import json
+import subprocess
+import sys
+from pathlib import PurePosixPath
+
+import yaml
+from packaging.version import InvalidVersion, Version
+
+EXTENSIONS_ROOT = "extensions"
+CATALOG_PATH = f"{EXTENSIONS_ROOT}/catalog.json"
+
+
+def _changed_paths(base_ref: str, head_ref: str) -> list[str]:
+    """Paths under extensions/ that differ between *base_ref* and *head_ref*.
+
+    Uses NUL-delimited output (``-z``): without it git C-quotes any path
+    containing non-ASCII or control characters (``"extensions/x/caf\\303\\251"``,
+    quotes included), so the leading component would no longer equal
+    ``extensions`` and that change would silently escape the guard. Paths
+    are decoded with surrogateescape so an undecodable byte can never crash
+    the check; only the ASCII ``extensions/<id>/`` prefix is interpreted.
+    """
+    raw = subprocess.run(
+        [
+            "git", "diff", "--name-only", "-z", "--no-renames",
+            base_ref, head_ref, "--", EXTENSIONS_ROOT,
+        ],
+        check=True,
+        capture_output=True,
+    ).stdout
+    return [
+        chunk.decode("utf-8", errors="surrogateescape")
+        for chunk in raw.split(b"\0")
+        if chunk
+    ]
+
+
+def _show(ref: str, path: str) -> str | None:
+    """Return the file's content at *ref*, or None when absent there."""
+    result = subprocess.run(
+        ["git", "show", f"{ref}:{path}"], capture_output=True, text=True
+    )
+    return result.stdout if result.returncode == 0 else None
+
+
+def _manifest_version(manifest_text: str, origin: str) -> str:
+    data = yaml.safe_load(manifest_text)
+    if not isinstance(data, dict) or not isinstance(data.get("extension"), dict):
+        raise ValueError(f"{origin}: manifest is not a mapping with an 'extension' block")
+    version = data["extension"].get("version")
+    if not isinstance(version, str) or not version.strip():
+        raise ValueError(f"{origin}: extension.version is missing or not a string")
+    return version.strip()
+
+
+def main(argv: list[str]) -> int:
+    if len(argv) < 2 or len(argv) > 3:
+        print(__doc__, file=sys.stderr)
+        return 2
+    base_ref = argv[1]
+    head_ref = argv[2] if len(argv) == 3 else "HEAD"
+
+    catalog_text = _show(head_ref, CATALOG_PATH)
+    if catalog_text is None:
+        print(f"::error::{CATALOG_PATH} is missing at {head_ref}")
+        return 1
+    catalog = json.loads(catalog_text)
+    catalog_entries = catalog.get("extensions", {})
+
+    errors: list[str] = []
+
+    # -- Invariant 1: content change requires a version bump ---------------
+    changed_ids = {
+        parts[1]
+        for path in _changed_paths(base_ref, head_ref)
+        if len(parts := PurePosixPath(path).parts) >= 3 and parts[0] == EXTENSIONS_ROOT
+    }
+
+    for ext_id in sorted(changed_ids):
+        if ext_id not in catalog_entries:
+            continue  # not driven by `extension update` (selftest, template)
+        manifest_path = f"{EXTENSIONS_ROOT}/{ext_id}/extension.yml"
+        head_manifest = _show(head_ref, manifest_path)
+        if head_manifest is None:
+            continue  # extension removed in this PR
+        try:
+            head_version = _manifest_version(head_manifest, f"{head_ref}:{manifest_path}")
+        except ValueError as exc:
+            errors.append(str(exc))
+            continue
+
+        # Parse the head version before the new-extension early return: the
+        # CLI's ExtensionManifest rejects a version packaging cannot parse and
+        # `extension update` skips catalog entries whose version is invalid,
+        # so a new extension shipped with e.g. "not-a-version" in both places
+        # would be uninstallable even though the catalog check below (plain
+        # string equality) passes. Same PEP 440 semantics as the CLI, so
+        # prereleases and other accepted forms are handled identically.
+        try:
+            head_parsed = Version(head_version)
+        except InvalidVersion as exc:
+            errors.append(
+                f"{manifest_path}: extension.version {head_version!r} is not a valid "
+                f"PEP 440 version ({exc}); the CLI rejects this manifest."
+            )
+            continue
+
+        base_manifest = _show(base_ref, manifest_path)
+        if base_manifest is None:
+            continue  # new extension; any valid initial version is fine
+        try:
+            base_version = _manifest_version(base_manifest, f"{base_ref}:{manifest_path}")
+        except ValueError as exc:
+            errors.append(str(exc))
+            continue
+
+        # Compare with the same PEP 440 semantics the extension update and
+        # install code use, so prereleases and other accepted forms cannot
+        # bypass the guard (e.g. 2.0.0 -> 1.0.0rc1 is a downgrade). An
+        # unparseable base version fails closed.
+        try:
+            base_parsed = Version(base_version)
+        except InvalidVersion as exc:
+            errors.append(
+                f"{manifest_path}: could not compare versions "
+                f"{base_version!r} -> {head_version!r}: {exc}"
+            )
+            continue
+        if head_parsed <= base_parsed:
+            errors.append(
+                f"{manifest_path}: files under {EXTENSIONS_ROOT}/{ext_id}/ changed but "
+                f"extension.version did not increase ({base_version} -> {head_version}). "
+                f"Installed copies only receive changes when the version is bumped."
+            )
+
+    # -- Invariant 2: catalog versions are valid and match the manifests ----
+    # Runs over every catalog entry, changed or not: a catalog-only entry
+    # (hosted elsewhere) never has files under extensions/<id>/, and a
+    # catalog-only promotion of an existing uncataloged directory never
+    # enters Invariant 1, so neither would otherwise have its version parsed.
+    for ext_id, entry in sorted(catalog_entries.items()):
+        catalog_version = entry.get("version") if isinstance(entry, dict) else None
+        if not isinstance(catalog_version, str) or not catalog_version.strip():
+            errors.append(f"{CATALOG_PATH}: entry '{ext_id}' has no string 'version'")
+            continue
+        # `extension update` skips a catalog entry whose version packaging
+        # cannot parse, so an invalid catalog version is never offered.
+        try:
+            Version(catalog_version)
+        except InvalidVersion as exc:
+            errors.append(
+                f"{CATALOG_PATH}: entry '{ext_id}' version {catalog_version!r} is not a "
+                f"valid PEP 440 version ({exc}); `extension update` skips such entries."
+            )
+            continue
+
+        manifest_path = f"{EXTENSIONS_ROOT}/{ext_id}/extension.yml"
+        head_manifest = _show(head_ref, manifest_path)
+        if head_manifest is None:
+            continue  # catalog-only entry (e.g. hosted elsewhere); version checked above
+        try:
+            manifest_version = _manifest_version(head_manifest, f"{head_ref}:{manifest_path}")
+        except ValueError as exc:
+            errors.append(str(exc))
+            continue
+        try:
+            Version(manifest_version)
+        except InvalidVersion as exc:
+            errors.append(
+                f"{manifest_path}: extension.version {manifest_version!r} is not a valid "
+                f"PEP 440 version ({exc}); the CLI rejects this manifest."
+            )
+            continue
+        if catalog_version != manifest_version:
+            errors.append(
+                f"{CATALOG_PATH}: entry '{ext_id}' has version {catalog_version!r} but "
+                f"{manifest_path} declares {manifest_version!r}. `extension update` "
+                f"compares against the catalog, so the two must move together."
+            )
+
+    for error in errors:
+        print(f"::error::{error}")
+    if not errors:
+        print("Extension version guard: all invariants hold.")
+    return 1 if errors else 0
+
+
+if __name__ == "__main__":
+    sys.exit(main(sys.argv))

specify_cli-1.0.6/.github/skills/code-review/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: code-review
+description: Reviews Spec Kit code changes for positive and negative test coverage, regression evidence for bug fixes, and consistent repository terminology. Use when reviewing a diff or pull request. Do not use for implementing changes or posting GitHub review actions.
+argument-hint: 'Diff or pull request to review'
+---
+
+# Code Review
+
+1. Ensure each code change has test cases that verify what the code should do and what it should prevent.
+2. Ensure bug-fix pull requests include a regression test that demonstrates the bug was reproducible before the change and is fixed afterward; if the reviewer cannot run the comparison, use available evidence and state that limitation.
+3. Ensure wording changes use repository-consistent terms; exclude community-authored catalog content and its generated documentation from this check.

specify_cli-1.0.6/.github/workflows/extension-version-guard.yml

@@ -0,0 +1,57 @@
+name: Extension Version Guard
+
+permissions:
+  contents: read
+
+# Bundled extensions only reach existing installs through a version bump:
+# `specify extension update` compares the semver in extensions/catalog.json
+# against the installed copy and reports "Up to date" whenever they match.
+# Content changes shipped without a bump go silently stale on every
+# project that already installed the extension (#4345). This guard turns
+# "please remember to bump" into a merge requirement.
+#
+# Deliberately no `paths:` filter: a required status check that is skipped
+# by path filtering stays in "Expected" state and blocks every PR that does
+# not touch extensions/**. The check runs on every pull request instead and
+# the script reports success when nothing under extensions/ changed.
+on:
+  pull_request:
+
+jobs:
+  version-bump:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          # The pull_request checkout is GitHub's merge of the PR head into
+          # the base tip. Depth 2 also fetches both parents of that merge
+          # commit, so HEAD^1 - the base the merge was actually built on -
+          # is available to diff against.
+          fetch-depth: 2
+
+      - name: Set up Python
+        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
+        with:
+          python-version: "3.14"
+
+      - name: Install check dependencies
+        run: python -m pip install --quiet pyyaml packaging
+
+      # Diff against the merge commit's first parent, NOT against
+      # github.event.pull_request.base.sha. The payload SHA is the base tip
+      # from when the PR was opened and is not refreshed when the base branch
+      # moves, while refs/pull/N/merge is rebuilt against the current tip.
+      # Diffing the stale SHA against the fresh merge commit attributes
+      # unrelated base-branch drift to the PR (observed on #4395: two
+      # unbumped extension changes merged to main were blamed on a PR that
+      # never touched them). HEAD^1 is by construction the base the merge
+      # was built on.
+      - name: Check bundled extension version bumps
+        run: |
+          set -euo pipefail
+          if ! git rev-parse --verify --quiet HEAD^2 >/dev/null; then
+            echo "::error::HEAD is not the pull request merge commit; cannot determine the PR base"
+            exit 1
+          fi
+          python .github/scripts/check_extension_version_bump.py HEAD^1

{specify_cli-1.0.5 → specify_cli-1.0.6}/.github/workflows/stale.yml

@@ -17,18 +17,18 @@ jobs:
       - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
         with:
           # Days of inactivity before an issue or PR becomes stale
-          days-before-stale: 150
+          days-before-stale: 60
           # Days of inactivity before a stale issue or PR is closed (after being marked stale)
           days-before-close: 30
 
           # Stale issue settings
-          stale-issue-message: 'This issue has been automatically marked as stale because it has not had any activity for 150 days. It will be closed in 30 days if no further activity occurs.'
-          close-issue-message: 'This issue has been automatically closed due to inactivity (180 days total). If you believe this issue is still relevant, please reopen it or create a new issue.'
+          stale-issue-message: 'This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed in 30 days if no further activity occurs.'
+          close-issue-message: 'This issue has been automatically closed due to inactivity (90 days total). If you believe this issue is still relevant, please reopen it or create a new issue.'
           stale-issue-label: 'stale'
 
           # Stale PR settings
-          stale-pr-message: 'This pull request has been automatically marked as stale because it has not had any activity for 150 days. It will be closed in 30 days if no further activity occurs.'
-          close-pr-message: 'This pull request has been automatically closed due to inactivity (180 days total). If you believe this PR is still relevant, please reopen it or create a new PR.'
+          stale-pr-message: 'This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed in 30 days if no further activity occurs.'
+          close-pr-message: 'This pull request has been automatically closed due to inactivity (90 days total). If you believe this PR is still relevant, please reopen it or create a new PR.'
           stale-pr-label: 'stale'
 
           # Exempt issues and PRs with these labels from being marked as stale

{specify_cli-1.0.5 → specify_cli-1.0.6}/CHANGELOG.md

@@ -2,6 +2,31 @@
 
 <!-- insert new changelog below this comment -->
 
+## [1.0.6] - 2026-09-10
+
+### Changed
+
+- fix(events): cap stdin in the generated dispatcher, not just the CLI command (#4337)
+- docs(core): SPECIFY_FEATURE sets the feature label, not the feature directory (#3786)
+- chore: shorten stale timeline to 60 days stale, 30 days to close (#4503)
+- [extension] Update Spec Kit Schedule extension to v0.7.4 (#4498)
+- [preset] Update Inventory Alignment preset to v0.1.1 (#4494)
+- Update Spec Inventory extension to v0.1.1 (#4496)
+- docs: document contribution evidence gate and label taxonomy (#4478)
+- feat(workflows): add per-step integration configuration (#4425)
+- fix: preserve extension authors in generated skills (#4459)
+- Add ProductShape PRODUCT workflows extension to community catalog (#4485)
+- Update AgentPay x402 extension to v1.1.0 (#4482)
+- Update Figma Starter extension to v1.1.0 (#4490)
+- Fix #4345 (3/4): CI guard requiring version bumps on bundled extension changes (#4395)
+- fix(templates): report an unreadable extensions.yml instead of skipping hooks silently (#4456)
+- Add concise code review skill (#4471)
+- docs(templates): clarify /constitution's Sync Impact Report is temporary, review-only material (#4431) (#4432)
+- fix(bundler): re-read the step registry when rolling back a failed step refresh (#4139)
+- Fix August newsletter review findings (#4444)
+- docs: resolve assess clarifications by editing artifacts in place (#4402)
+- chore: release 1.0.5, begin 1.0.6.dev0 development (#4479)
+
 ## [1.0.5] - 2026-09-08
 
 ### Changed

{specify_cli-1.0.5 → specify_cli-1.0.6}/CONTRIBUTING.md

@@ -57,6 +57,84 @@ Here are a few things you can do that will increase the likelihood of your pull
 
 Accounts with three open pull requests may continue submitting changes, but additional submissions may be placed behind contributions from other authors in the review queue. Coding agents should disclose this possibility and obtain the filer's confirmation before opening another pull request.
 
+### Evidence gate
+
+A contribution is evaluated on the evidence it carries, not on how plausible its reasoning sounds. The same bar applies to everyone — human and AI-assisted contributions are judged identically.
+
+A valid, in-scope change that arrives without evidence is not rejected outright. It may be labeled [`triage-can-wait`](#triage-and-author-labels) and held behind proven work until evidence is added, at which point it can be reprioritized.
+
+What counts as evidence:
+
+- **A reproduction or a linked real-world report** — a failing case, a stack trace, or a link to an issue where the problem actually occurred. "This could theoretically fail" reasoning on its own does not clear the gate.
+- **A regression test that fails on `main` and passes with your change** — this proves both that the problem is real and that your change fixes it.
+- **Scope discipline** — one concern per pull request. Split unrelated changes into separate PRs (see the [focused-change guidance](#submitting-a-pull-request) above); sprawling batch diffs are hard to review and slow to land.
+- **Disclosed AI assistance** — if any AI tooling was involved, disclose it and its extent per [AI contributions in Spec Kit](#ai-contributions-in-spec-kit).
+
+Speculative hardening is welcome, but it sits behind proven, evidence-backed work. If you can attach a reproduction and a failing test, your change moves to the front; if you can't yet, say so, and it will be queued rather than closed.
+
+### Review rubric
+
+Triaged items are weighed across seven dimensions, each scored `0`–`2` (`0` absent, `1` partial, `2` clearly demonstrated), for a maximum of 14. The score guides **prioritization** — it is not a hard pass/fail gate. The one firm rule is the [evidence gate](#evidence-gate) above: theoretical-only changes with no evidence are deprioritized.
+
+| Dimension | What it measures |
+|---|---|
+| D1 — Real-world evidence | A reproduction or linked report, versus theory alone |
+| D2 — Reachability / severity | Whether the issue can actually be hit, and how bad it is |
+| D3 — Scope discipline | One focused concern per PR, no unrelated changes |
+| D4 — Test evidence | A regression test that fails on `main` and passes with the change |
+| D5 — Disclosure / understanding | AI use disclosed, and the author understands the change |
+| D6 — Cost vs. benefit | Value delivered against added complexity and maintenance cost |
+| D7 — Roadmap alignment | Fit with Spec Kit's goals and direction |
+
+### Triage and author labels
+
+Every triaged item receives one **verdict** label recording where it stands. **Author** labels signal the specific action needed to move an item forward.
+
+Verdict (one per item):
+
+| Label | Meaning |
+|---|---|
+| `triage-must-have` | Verdict: high-value, important work for Spec Kit — do first |
+| `triage-nice-to-have` | Verdict: evidence-backed fix or greenlit feature — land after review |
+| `triage-can-wait` | Verdict: valid and in-scope but deprioritized; held behind the evidence gate |
+| `triage-out-of-scope` | Verdict: won't land in core — invalid, duplicate, off-mission, or redirected to an extension |
+
+Author actions:
+
+| Label | Meaning |
+|---|---|
+| `author-needs-proof` | The problem isn't demonstrated yet — supply a reproduction or a test that fails on `main` and passes with the change |
+| `author-needs-tests` | Real change but missing a regression test — add one that fails before / passes after |
+| `author-needs-rescope` | Sprawling or batched diff — split into one focused, single-concern PR |
+| `author-needs-disclosure` | AI assistance not disclosed — disclose AI use per CONTRIBUTING |
+| `author-needs-info` | Missing detail needed to assess — supply requested info |
+| `author-needs-rebase` | Branch conflicts with `main` — rebase and resolve before it can be merged |
+| `author-over-cap` | Over the 3-open-PR cap or repetitive batch submissions — please consolidate |
+| `author-awaiting` | Waiting on author response (handed off to the existing stale workflow) |
+
+Some pull requests are closed as `triage-out-of-scope` rather than merged — most commonly
+when the same change is already in `main`, when a request is better served as a community
+extension, when an existing feature already covers it, or when a catalog change came in as
+a direct edit instead of a submission issue. A close always comes with a comment explaining
+why and, where relevant, where to go instead.
+
+For further reading on the thinking behind this gate, see [one maintainer's perspective on AI-sourced contributions](https://blog.manorrock.com/blog/2026/09/08/spec_kit_ai_source.html). That piece is a personal viewpoint, not project policy — the policy is what's documented here.
+
+### Community catalog submissions
+
+To add or update a community extension, preset, or bundle in the catalog, **open an
+`[Extension]` / `[Preset]` / `[Bundle]` submission issue** — do not edit
+`extensions/catalog.community.json` (or the preset/bundle catalogs) directly in a pull
+request. The submission issue triggers an automated workflow that validates the release,
+verifies the pinned `download_url` and digests, and generates the catalog PR for you.
+A hand-edited catalog PR bypasses that validation and will be closed with a pointer back
+to the issue flow.
+
+This applies to **new entries, version updates, and repairs alike** — a version bump or a
+fix to a broken entry is still an update and needs the same validation. Always pin
+`download_url` to a release tag (e.g. `.../releases/download/<tag>/...` or
+`.../archive/refs/tags/<tag>.zip`); never use `releases/latest/`.
+
 ### Branch naming
 
 We recommend naming branches as `<type>/<number>-<short-slug>`, where `<number>` is the issue or PR number (whichever comes first) and `<type>` is one of:

{specify_cli-1.0.5 → specify_cli-1.0.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.0.5
+Version: 1.0.6
 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-1.0.5 → specify_cli-1.0.6}/docs/community/extensions.md

@@ -30,7 +30,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Agent Governance | Generate agent-platform repository governance files from Spec Kit metadata | `process` | Read+Write | [spec-kit-agent-governance](https://github.com/bigsmartben/spec-kit-agent-governance) |
 | AgentDocx | Full-stack multi-agent specification pipeline with VS Code extension control, automated Kanban/Jira sync, and React monitoring dashboard | `integration` | Read+Write | [extension-github-spec-kit](https://github.com/abir-ommezzine/extension-github-spec-kit) |
 | AgentDocx SpecKit V2 | AgentDocx evolved: same pipeline + far more autonomous Ticket Manager (5 CLI, per-project Kanban, bulk sync, auto-switch, Auditor) | `integration` | Read+Write | [Extension_GithubSpecKit](https://github.com/ahmed200346/Extension_GithubSpecKit) |
-| AgentPay x402 — Spend Controls for Spec Kit Agents | Set USDC spending caps and execute x402 payments to paid APIs during spec implementation. Zero platform fee on Base L2 | `integration` | Read+Write | [spec-kit-pay-x402](https://github.com/shawnhvac/spec-kit-pay-x402) |
+| AgentPay x402 — Spend Controls for Spec Kit Agents | Set USDC spending caps, check a counterparty's credit before paying it, and pay x402-enabled APIs during spec implementation. Settles on Base or Solana. | `integration` | Read+Write | [spec-kit-pay-x402](https://github.com/shawnhvac/spec-kit-pay-x402) |
 | AI-Driven Engineering (AIDE) | A structured 7-step workflow for building new projects from scratch with AI assistants — from vision through implementation | `process` | Read+Write | [aide](https://github.com/mnriem/spec-kit-extensions/tree/main/aide) |
 | Analytics | Measure what your AI builds, and how much time it saves you | `visibility` | Read+Write | [spec-kit-analytics](https://github.com/Fyloss/spec-kit-analytics) |
 | API Evolve | Managed API contract evolution — breaking-change detection, semver enforcement, deprecation orchestration, and lifecycle gates across REST, GraphQL, and gRPC | `process` | Read+Write | [spec-kit-api-evolve](https://github.com/Quratulain-bilal/spec-kit-api-evolve) |
@@ -69,7 +69,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | EARS Requirements Syntax | Author, lint, and convert requirements using EARS - the five industry-standard sentence patterns for unambiguous, testable requirements | `docs` | Read+Write | [spec-kit-ears](https://github.com/dhruv-15-03/spec-kit-ears) |
 | Evaluator Contract | Provider-neutral evaluator contract for evidence, provenance, uncertainty, and recovery across Spec-Driven Development phases. | `process` | Read+Write | [spec-kit-evaluator](https://github.com/electrohire/spec-kit-evaluator) |
 | Extensify | Create and validate extensions and extension catalogs | `process` | Read+Write | [extensify](https://github.com/mnriem/spec-kit-extensions/tree/main/extensify) |
-| Figma Starter | Turns a Figma section's screens into per-screen spec.md files, an app-level user-stories.md, and a build-order.md, then hands off to /speckit.specify | `integration` | Read+Write | [spec-kit-figma-starter](https://github.com/wavemaker/spec-kit-figma-starter) |
+| Figma Starter | Turns a Figma section's screens into Figma-derived specs, and an OpenAPI/Swagger document into an entity model plus per-page UI-to-API bindings, then hands off to /speckit.specify | `docs` | Read+Write | [spec-kit-figma-starter](https://github.com/OmneWave/spec-kit-figma-starter) |
 | Fix Findings | Automated analyze-fix-reanalyze loop that resolves spec findings until clean | `code` | Read+Write | [spec-kit-fix-findings](https://github.com/Quratulain-bilal/spec-kit-fix-findings) |
 | FixIt Extension | Spec-aware bug fixing — maps bugs to spec artifacts, proposes a plan, applies minimal changes | `code` | Read+Write | [spec-kit-fixit](https://github.com/speckit-community/spec-kit-fixit) |
 | Fleet Orchestrator | Orchestrate a full feature lifecycle with human-in-the-loop gates across all SpecKit phases | `process` | Read+Write | [spec-kit-fleet](https://github.com/sharathsatish/spec-kit-fleet) |
@@ -119,6 +119,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Presetify | Create and validate presets and preset catalogs | `process` | Read+Write | [presetify](https://github.com/mnriem/spec-kit-extensions/tree/main/presetify) |
 | Product Forge | Full product-lifecycle orchestrator for Spec Kit: research → product-spec → plan → tasks → implement → verify → test → release-readiness, across express/lite/standard/v-model modes with human-in-the-loop gates. | `process` | Read+Write | [speckit-product-forge](https://github.com/VaiYav/speckit-product-forge) |
 | Product Spec Extension | Generates PRFAQ, Lean PRD, stakeholder summaries, and technical designs from engineering specs | `docs` | Read+Write | [spec-kit-product](https://github.com/d0whc3r/spec-kit-product) |
+| ProductShape PRODUCT workflows | Author, refine, validate, apply, archive and recover ProductShape product meaning in a separate Spec Kit lane. | `process` | Read+Write | [productshape](https://github.com/juangcarmona/productshape) |
 | Project Health Check | Diagnose a Spec Kit project and report health issues across structure, agents, features, scripts, extensions, and git | `visibility` | Read-only | [spec-kit-doctor](https://github.com/KhawarHabibKhan/spec-kit-doctor) |
 | Project Status | Show current SDD workflow progress — active feature, artifact status, task completion, workflow phase, and extensions summary | `visibility` | Read-only | [spec-kit-status](https://github.com/KhawarHabibKhan/spec-kit-status) |
 | QA Testing Extension | Systematic QA testing with browser-driven or CLI-based validation of acceptance criteria from spec | `code` | Read-only | [spec-kit-qa](https://github.com/arunt14/spec-kit-qa) |
@@ -147,7 +148,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Spec Kit Figma | Grounds SpecKit spec/plan/tasks in Figma design context via REST or MCP, on macOS/Linux/Windows. | `integration` | Read+Write | [spec-kit-figma](https://github.com/Fyloss/spec-kit-figma) |
 | Spec Kit Memory | Recalls prior specs and decisions from configurable memory tools (e.g. memsearch) before SDLC stages, so planning and specification start from what the project already knows | `docs` | Read+Write | [spec-kit-memory](https://github.com/zaytsevand/spec-kit-memory) |
 | Spec Kit Preview | Generate evidence-backed low, mid, or high fidelity previews from Spec Kit artifacts as Markdown or self-contained HTML | `docs` | Read+Write | [spec-kit-preview](https://github.com/bigsmartben/spec-kit-preview) |
-| Spec Kit Schedule | Optimal multi-agent task scheduling via CP-SAT — DAG precedence, hallucination-aware caps, file-conflict avoidance, stochastic durations, replanning, and interactive HTML output | `process` | Read+Write | [spec-kit-schedule](https://github.com/jfranc38/spec-kit-schedule) |
+| Spec Kit Schedule — parallel subagent rounds | Zero-config planner that turns tasks.md into optimal parallel rounds for subagents (CP-SAT, critical-path aware, file-conflict safe) and an implement command that runs them round by round with tasks.md checkboxes as the single source of progress. | `process` | Read+Write | [spec-kit-schedule](https://github.com/jfranc38/spec-kit-schedule) |
 | Spec Kit TLDR | Render a feature's spec.md / plan.md into a review-oriented TLDR (self-contained HTML dashboard + PR-native Markdown) that surfaces risks for faster PR review. | `visibility` | Read+Write | [speckit-tldr](https://github.com/qurore/speckit-tldr) |
 | Spec Orchestrator | Cross-feature orchestration — track state, select tasks, and detect conflicts across parallel specs | `process` | Read-only | [spec-kit-orchestrator](https://github.com/Quratulain-bilal/spec-kit-orchestrator) |
 | Spec Reference Loader | Reads the ## References section from the feature spec and loads only the listed docs into context | `docs` | Read-only | [spec-kit-spec-reference-loader](https://github.com/KevinBrown5280/spec-kit-spec-reference-loader) |

{specify_cli-1.0.5 → specify_cli-1.0.6}/docs/reference/core.md

@@ -53,7 +53,7 @@ specify init my-project --integration copilot --preset compliance
 | `SPECKIT_INTEGRATION_DEFAULT` | Override the fallback integration used by `specify init` when `--integration` is omitted (interactive prompt default and non-interactive fallback). Set it to any registered integration key (e.g. `gemini`, `claude`). An unrecognized value is ignored with a warning and the built-in default (`copilot`) is used. An explicit `--integration <key>` always takes precedence. |
 | `SPECIFY_INIT_DIR` | Target a member project from outside its directory (e.g. a monorepo root) without `cd`, for non-interactive / CI use. Set it to the **project root** — the directory *containing* `.specify/` (relative paths resolve against the current directory). The path must exist and contain `.specify/`, otherwise the command errors and does **not** fall back to the current directory. Resolved once in the core root helper (`get_repo_root` in Bash, `Get-RepoRoot` in PowerShell), so it is honored by the core feature scripts (`/speckit.plan`, `/speckit.tasks`, …) and the Git extension's feature-branch creation, which inherit it. The `specify` CLI applies the **same** validation rules to every project-scoped subcommand (`specify integration …`, `specify extension …`, `specify workflow …`, `specify preset …`, and the rest that operate on a `.specify/` project), so those can target a member project too. When unset, Bash/PowerShell helpers keep their existing upward search; the `specify` CLI keeps its project-scoped resolver cwd-only unless a command explicitly defines broader detection (for example, bundle commands). |
 | `SPECIFY_FEATURE_DIRECTORY` | Override the active feature directory *within* the resolved project (takes precedence over `.specify/feature.json`). Relative paths resolve under the project root. Combine with `SPECIFY_INIT_DIR` to pick both the project and the feature non-interactively. |
-| `SPECIFY_FEATURE` | Override feature detection for non-Git repositories. Set to the feature directory name (e.g., `001-photo-albums`) to work on a specific feature when not using Git branches. Must be set in the context of the agent prior to using `/speckit.plan` or follow-up commands. |
+| `SPECIFY_FEATURE` | Explicitly override the active feature **label** (e.g. `001-photo-albums`) — the identifier the core helpers report as the current feature/branch (`get_current_branch` in Bash, `Get-CurrentBranch` in PowerShell). Those helpers never inspect Git: when the variable is set they return it verbatim, and when it is unset they return an empty string. The basename fallback happens later — `get_feature_paths` / `Get-FeaturePathsEnv` substitute the resolved feature directory's basename so the reported label is still usable — so calling the named helpers directly does **not** give you that fallback. You set it yourself: the Bash and Python feature scripts only **print** a commented `export SPECIFY_FEATURE=…` / `$env:SPECIFY_FEATURE = …` hint for you to run, because a child process cannot change its parent's environment, and `/speckit.specify` persists `feature_directory` to `.specify/feature.json` instead of setting this variable. (The PowerShell feature scripts do assign `$env:SPECIFY_FEATURE`, but that only reaches you when the script runs inside your current PowerShell session.) It does **not** locate the feature directory: with only `SPECIFY_FEATURE` set, `get_feature_paths` fails with *"Feature directory not found. Set `SPECIFY_FEATURE_DIRECTORY` or run the specify command to create `.specify/feature.json`."* Use `SPECIFY_FEATURE_DIRECTORY` (above) or `.specify/feature.json` to select the directory. |
 
 > **Two resolution axes.** `SPECIFY_INIT_DIR` selects the **project** (which directory contains `.specify/`); `SPECIFY_FEATURE_DIRECTORY` / `.specify/feature.json` select the **feature** within that project. They are independent — project first, then feature.
 

{specify_cli-1.0.5 → specify_cli-1.0.6}/docs/reference/workflows.md

@@ -540,6 +540,44 @@ specify workflow run speckit -i spec="Build a kanban board with drag-and-drop ta
 
 > **Security note:** a `shell` step runs a local command with **your** privileges. There is no capability sandbox — `requires` is an advisory pre-condition block (spec-kit version, integrations), not a runtime gate, so it does **not** restrict what a step can do. In particular there is no `requires.permissions` capability gate: it is rejected by validation precisely because it would imply a sandbox that does not exist. Review any catalog or downloaded workflow before running it, and use a `gate` step to require explicit approval before sensitive or destructive shell commands.
 
+### Per-Step Integration Configuration
+
+Command steps may pass structured runtime configuration to integrations that
+support it:
+
+```yaml
+- id: implement-with-docker-agent
+  type: command
+  command: speckit.implement
+  integration: docker-agent
+  integration_args:
+    - "{{ inputs.agent_config }}"
+  integration_options:
+    agent: root
+    safety: balanced
+  model: "openai/gpt-5"
+  input:
+    args: "{{ inputs.spec }}"
+```
+
+`integration_args` is an ordered list of strings. `integration_options` is a
+mapping with string keys. Values in both fields are resolved with the workflow
+expression mechanism and validated by the selected integration; unsupported,
+unknown, or malformed values fail with an actionable error. Docker Agent uses
+its single positional argument as the agent configuration reference and accepts
+`agent` and `safety` as named integration options. Configure its model through
+the command step's top-level `model` field.
+
+When Docker Agent `integration_args` supplies an agent reference for a command
+step, it takes precedence over `SPECKIT_INTEGRATION_DOCKER_AGENT_EXTRA_ARGS`;
+the entire legacy environment value is ignored for that step. Without a per-step
+agent reference, the legacy environment behavior is unchanged.
+
+Resolved runtime configuration is recorded in workflow run state. When a failed
+or paused command is resumed, the complete dispatch configuration is re-resolved
+from the current inputs, so values supplied with `workflow resume --input` take
+effect consistently. A resume without updated inputs reproduces the same values.
+
 ## Expressions
 
 Steps can reference inputs and previous step outputs using `{{ expression }}` syntax:

{specify_cli-1.0.5 → specify_cli-1.0.6}/extensions/EXTENSION-DEVELOPMENT-GUIDE.md

@@ -625,6 +625,13 @@ See the [Extension Publishing Guide](EXTENSION-PUBLISHING-GUIDE.md) for detailed
 - **MAJOR**: Breaking changes
 - **MINOR**: New features
 - **PATCH**: Bug fixes
+- **Bump on every content change**: update offers from `specify extension
+  update` are version-driven, so a content change shipped without a
+  version bump is never delivered automatically to already-installed
+  copies. For the bundled extensions in this repository the bump is
+  enforced by CI (`extension-version-guard.yml`): a PR that changes
+  files under `extensions/<id>/` must also bump that extension's
+  `extension.yml` version and keep `extensions/catalog.json` in sync.
 
 ### Security
 

{specify_cli-1.0.5 → specify_cli-1.0.6}/extensions/assess/README.md

@@ -26,7 +26,8 @@ flowchart LR
     A[intake] --> R[research] --> D[define] --> S[shape] --> C{decide}
     C -->|go| SPEC[/speckit.specify/]
     C -->|kill| X[closed, recorded]
-    C -.->|needs-clarification: revisit the named earlier stage| A
+    C -.->|needs-clarification| F[refine named artifact in place]
+    F -.->|then revise decision.md| C
 ```
 
 ## Commands
@@ -45,6 +46,27 @@ Stages are meant to run in order but are not rigidly gated:
 - `shape` requires `problem.md`.
 - `decide` requires `problem.md`; a `go` verdict expects `concept.md` (otherwise it is downgraded to `needs-clarification`).
 
+## Resolving clarifications
+
+The normal process is sequential and each command usually runs **once**:
+
+```text
+intake → research → define → shape → decide
+```
+
+Each stage writes a Markdown artifact under `.specify/assessments/<slug>/`. Those files stay editable. The commands keep their existing output templates: they do not rewrite an earlier artifact or perform that refinement themselves. `[NEEDS CLARIFICATION: …]` markers are gaps in the artifact, not a signal to regenerate the whole stage from scratch.
+
+Resolve them by refining the existing file:
+
+1. **Edit the Markdown directly** (fill in the missing metric, owner, constraint, and so on), or
+2. **Ask the agent in free-form chat** to incorporate the missing information into that artifact.
+
+Then ask whether the new information clears the blocker and to update any downstream wording that depended on it. That includes `decision.md`: you can supply the missing facts and ask the agent to revise the scorecard, rationale, verdict, or handoff. That is artifact refinement, not command iteration.
+
+When you add evidence, keep the source and confidence tags the research stage already uses (`ASSUMPTION` vs cited claims). Do not invent citations.
+
+Rerunning an earlier `speckit.assess.*` command is the exception (for example after a wrong slug or a discarded draft), not the default path for answering clarification markers.
+
 ## Slug Conventions
 
 A *slug* is the per-idea directory name under `.specify/assessments/`. It is the handle all five commands share.