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

{specify_cli-1.0.4 → specify_cli-1.0.6}/.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**: Alquimia AI, Amp, Antigravity, Auggie CLI, Claude Code, Cline, CodeBuddy, Codex CLI, Command Code, Cursor, Devin for Terminal, Docker Agent, Factory Droid, DeepSeek Harness, 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**: Alquimia AI, Amp, Antigravity, Auggie CLI, Claude Code, Cline, CodeBuddy, Codex CLI, Command Code, Cursor, Devin for Terminal, Docker Agent, Factory Droid, DeepSeek Harness, Firebender, Forge, Gemini CLI, GitHub Copilot, Goose, Grok Build, Hermes Agent, IBM Bob, Junie, Kilo Code, Kimi Code, Kiro CLI, Lingma, Mistral Vibe, Muse Code, 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-1.0.4 → specify_cli-1.0.6}/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -90,6 +90,7 @@ body:
         - Kiro CLI
         - Lingma
         - Mistral Vibe
+        - Muse Code
         - Oh My Pi
         - opencode
         - Pi Coding Agent

{specify_cli-1.0.4 → specify_cli-1.0.6}/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -84,6 +84,7 @@ body:
         - Kiro CLI
         - Lingma
         - Mistral Vibe
+        - Muse Code
         - Oh My Pi
         - opencode
         - Pi Coding Agent

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.4 → specify_cli-1.0.6}/.github/workflows/codeql.yml

@@ -22,11 +22,11 @@ jobs:
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
 
       - name: Initialize CodeQL
-        uses: github/codeql-action/init@db488ddef3bf6cb639b32c2e9a7c0a7ea8271d28 # v4
+        uses: github/codeql-action/init@cdf488f595d80d6e07e03d4674febd5ab45fa938 # v4
         with:
           languages: ${{ matrix.language }}
 
       - name: Perform CodeQL Analysis
-        uses: github/codeql-action/analyze@db488ddef3bf6cb639b32c2e9a7c0a7ea8271d28 # v4
+        uses: github/codeql-action/analyze@cdf488f595d80d6e07e03d4674febd5ab45fa938 # v4
         with:
           category: "/language:${{ matrix.language }}"

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.4 → 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.4 → specify_cli-1.0.6}/CHANGELOG.md

@@ -2,6 +2,56 @@
 
 <!-- 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
+
+- Update OKF Knowledge Bundle Generator to v0.5.0 (#4475)
+- Update BrownKit extension to v1.2.0 (#4474)
+- chore(deps): bump the codeql-action group with 2 updates (#4436)
+- fix(tasks): require field constraints from data-model.md in generated tasks (#4430)
+- fix(workflows): reject falsy non-mapping step.yml in step add (#4321)
+- fix(cline): stop unrelated prose from suppressing the hook command note (#4150)
+- Add the August 2026 newsletter (#4442)
+- Update Linear Integration extension to v0.8.0 (#4428)
+- fix(presets): reject falsy non-mapping catalog config shapes (#4320)
+- docs(workflows): sync the reference copy with the shipped workflow (#4424)
+- fix(scripts): name setup-plan's feature directory key FEATURE_DIR (#4397)
+- fix(workflows): require a 'steps' body on while and do-while loops (#4149)
+- Add Evaluator Contract extension to community catalog (#4420)
+- fix: remove unused scope input from bundled speckit workflow (#4401)
+- feat(integrations): add Muse Code (muse) agent integration (#4413)
+- feat(workflows): add workflow slots (#4352)
+- fix(scripts): make bash branch-name sanitizing match the Python and PowerShell twins (#4286)
+- allow hyphen in command ref token names (#4356)
+- [extension] Add Axi Extension to community catalog (#4412)
+- chore: release 1.0.4, begin 1.0.5.dev0 development (#4411)
+
 ## [1.0.4] - 2026-09-02
 
 ### Changed

{specify_cli-1.0.4 → 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.4 → specify_cli-1.0.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.0.4
+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.4 → 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) |
@@ -41,6 +41,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Archive Extension | Archive merged features into main project memory, resolving gaps and conflicts. | `docs` | Read+Write | [spec-kit-archive](https://github.com/stn1slv/spec-kit-archive) |
 | ASCII Diagram Renderer | Renders hand-drawn ASCII/Unicode diagrams (state machine, architecture, flow, coverage map) of what spec/plan/tasks/analyze already say — plain text, no Mermaid renderer needed | `docs` | Read+Write | [spec-kit-ascii-diagram](https://github.com/MRZHUH/spec-kit-ascii-diagram) |
 | Atlas | Synthesize spec-kit specs into faithful, interactive architecture storybooks & doc portals. | `docs` | Read-only | [spec-kit-atlas](https://github.com/ashbrener/spec-kit-atlas) |
+| Axi Extension | A Spec Kit extension that renders a feature's markdown in a local browser review surface for human annotation, then returns the queued notes to the agent to apply. | `docs` | Read+Write | [spec-kit-axi](https://github.com/d0whc3r/spec-kit-axi) |
 | Azure Cosmos DB | Best-practice Azure Cosmos DB code generation and review for any AI coding agent | `code` | Read+Write | [spec-kit-cosmosdb](https://github.com/AzureCosmosDB/spec-kit-cosmosdb) |
 | Azure DevOps Integration | Sync user stories and tasks to Azure DevOps work items using OAuth authentication | `integration` | Read+Write | [spec-kit-azure-devops](https://github.com/pragya247/spec-kit-azure-devops) |
 | BDD | Convert specs to Gherkin scenarios, scaffold step definitions, and verify acceptance test coverage | `process` | Read+Write | [spec-kit-bdd](https://github.com/RSginer/spec-kit-bdd) |
@@ -48,7 +49,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Blueprint Index — Living Architecture Map | A living architecture map for spec-driven projects, kept honest by a deterministic, low-friction, machine-first CI gate (JSON, self-healable) that blocks only when the map contradicts the specs or code. Brownfield or greenfield. | `process` | Read+Write | [spec-kit-blueprint](https://github.com/ogil109/spec-kit-blueprint) |
 | Branch Convention | Configurable branch and folder naming conventions for /specify with presets and custom patterns | `process` | Read+Write | [spec-kit-branch-convention](https://github.com/Quratulain-bilal/spec-kit-branch-convention) |
 | Brownfield Bootstrap | Bootstrap spec-kit for existing codebases — auto-discover architecture and adopt SDD incrementally | `process` | Read+Write | [spec-kit-brownfield](https://github.com/Quratulain-bilal/spec-kit-brownfield) |
-| BrownKit | Evidence-driven capability discovery, security and QA risk assessment for existing codebases | `process` | Read+Write | [BrownKit](https://github.com/MaksimShevtsov/BrownKit) |
+| BrownKit — Brownfield Discovery for Spec-Kit | Evidence-driven capability discovery, security and QA risk assessment for existing codebases. | `process` | Read+Write | [BrownKit](https://github.com/MaksimShevtsov/BrownKit) |
 | Bugfix Workflow | Structured bugfix workflow — capture bugs, trace to spec artifacts, and patch specs surgically | `process` | Read+Write | [spec-kit-bugfix](https://github.com/Quratulain-bilal/spec-kit-bugfix) |
 | Canon | Adds canon-driven (baseline-driven) workflows: spec-first, code-first, spec-drift. Requires Canon Core preset installation. | `process` | Read+Write | [spec-kit-canon](https://github.com/maximiliamus/spec-kit-canon/tree/master/extension) |
 | Catalog CI | Automated validation for spec-kit community catalog entries — structure, URLs, diffs, and linting | `process` | Read-only | [spec-kit-catalog-ci](https://github.com/Quratulain-bilal/spec-kit-catalog-ci) |
@@ -66,8 +67,9 @@ The following community-contributed extensions are available in [`catalog.commun
 | Dotdog | Import GitHub Spec Kit artifacts into local knowledge graphs for validation, analysis, search, and MCP queries. | `docs` | Read+Write | [dotdog](https://github.com/specdog/dotdog) |
 | DUBSAR Memory | Local project memory for Spec Kit with explicit checkpoints, cross-session resume, and SHA-256 freshness for recorded specification, plan, and task references. | `visibility` | Read+Write | [dubsar-memory](https://github.com/kotnisofiane-bit/dubsar-memory) |
 | 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) |
@@ -84,7 +86,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Jira Mirror | Spec Kit ↔ Jira bridge for team-managed and company-managed projects: configurable workflows & hierarchies (Scrum/SAFe), multi-project, idempotent and fail-closed. macOS/Linux/Windows. | `integration` | Read+Write | [spec-kit-jira-mirror](https://github.com/Fyloss/spec-kit-jira-mirror) |
 | Keel Discovery | Evidence-backed discovery upstream of /speckit.specify, plus round-trip drift auditing after implementation | `process` | Read+Write | [spec-kit-keel](https://github.com/keeldiscovery/spec-kit-keel) |
 | Learning Extension | Generate educational guides from implementations and enhance clarifications with mentoring context | `docs` | Read+Write | [spec-kit-learn](https://github.com/imviancagrace/spec-kit-learn) |
-| Linear Integration | Mirror spec-kit feature directories into Linear (filesystem → Linear, reconcile-based, unidirectional). | `integration` | Read+Write | [spec-kit-linear-sync](https://github.com/ashbrener/spec-kit-linear-sync) |
+| Linear Integration | Automatically mirror your spec-kit specs into Linear — one issue per spec, a sub-issue per task phase, kept in sync as you work. | `integration` | Read+Write | [spec-kit-linear-sync](https://github.com/ashbrener/spec-kit-linear-sync) |
 | Linear Weave | Weave Spec Kit into Linear: pull requirements, mirror tasks.md into sub-issues, sync statuses | `integration` | Read+Write | [spec-kit-linear-weave](https://github.com/tonydwoodhouse/spec-kit-linear-weave) |
 | LLM Wiki | LLM-maintained compounding project wiki: source ingestion, cited answers, and consistency linting | `docs` | Read+Write | [spec-kit-wiki](https://github.com/formin/spec-kit-wiki) |
 | Loop Engineering | Engineer safe autonomous agent loops for spec-driven development: a maker/checker split, externalized loop state, and stay-the-engineer guardrails against comprehension debt and cognitive surrender | `process` | Read+Write | [spec-kit-loop](https://github.com/formin/spec-kit-loop) |
@@ -105,7 +107,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Multi-Repo Branch Sync | Creates the feature branch in affected sub-repositories and git submodules via plan/tasks hooks | `process` | Read+Write | [multi-repo-sync](https://github.com/fyloss/spec-kit-multi-repo-sync) |
 | Multi-Sites Spec Kit | Multi-site aware specify command with per-site spec folders, auto-increment, and Drupal support | `process` | Read+Write | [spec-kit-multi-sites](https://github.com/teeyo/spec-kit-multi-sites) |
 | .NET Framework to Modern .NET Migration | Orchestrate end-to-end .NET Framework to modern .NET migration across 7 phases, with SDD lifecycle integration | `process` | Read+Write | [spec-kit-fx-to-net](https://github.com/RogerBestMsft/spec-kit-FxToNet) |
-| OKF Knowledge Bundle Generator | Generates and maintains an Open Knowledge Format (OKF v0.1) knowledge bundle from a source-code repository, mining git history for significance and rationale, and resolving open questions with the user | `docs` | Read+Write | [speckit_ofk](https://github.com/alexcpn/speckit_ofk) |
+| OKF Knowledge Bundle Generator | Generates and maintains an Open Knowledge Format (OKF v0.1) knowledge bundle from a source-code repository, mining git history for rationale and parking what it cannot verify as open questions | `docs` | Read+Write | [speckit_okf](https://github.com/alexcpn/speckit_okf) |
 | Onboard | Contextual onboarding and progressive growth for developers new to spec-kit projects. Explains specs, maps dependencies, validates understanding, and guides the next step | `process` | Read+Write | [spec-kit-onboard](https://github.com/dmux/spec-kit-onboard) |
 | Optimize | Audit and optimize AI governance for context efficiency — token budgets, rule health, interpretability, compression, coherence, and echo detection | `process` | Read+Write | [spec-kit-optimize](https://github.com/sakitA/spec-kit-optimize) |
 | Orchestration Task Context Management | Adds subagent work-unit orchestration to generated Spec Kit task files | `process` | Read+Write | [spec-kit-orchestration-task-context-management](https://github.com/benizzio/spec-kit-orchestration-task-context-management) |
@@ -117,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) |
@@ -145,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.4 → 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.