specify-cli 1.0.11__tar.gz → 1.0.13__tar.gz

{specify_cli-1.0.11 → specify_cli-1.0.13}/.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, Muse Code, 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, MiniMax Code, 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.11 → specify_cli-1.0.13}/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -89,6 +89,7 @@ body:
         - Kimi Code
         - Kiro CLI
         - Lingma
+        - MiniMax Code
         - Mistral Vibe
         - Muse Code
         - Oh My Pi

{specify_cli-1.0.11 → specify_cli-1.0.13}/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -83,6 +83,7 @@ body:
         - Kimi Code
         - Kiro CLI
         - Lingma
+        - MiniMax Code
         - Mistral Vibe
         - Muse Code
         - Oh My Pi

{specify_cli-1.0.11 → specify_cli-1.0.13}/.github/workflows/codeql.yml

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

{specify_cli-1.0.11 → specify_cli-1.0.13}/.github/workflows/lint.yml

@@ -10,6 +10,20 @@ on:
 jobs:
   markdownlint:
     runs-on: ubuntu-latest
+    env:
+      DOC_GLOBS: |
+        docs/**/*.md
+        README.md
+        README.zh-CN.md
+        CODE_OF_CONDUCT.md
+        CONTRIBUTING.md
+        DEVELOPMENT.md
+        SECURITY.md
+        SUPPORT.md
+        spec-driven.md
+        integrations/*.md
+        presets/*.md
+        workflows/*.md
     steps:
       - name: Checkout
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
@@ -36,12 +50,46 @@ jobs:
             git diff --check refs/checks/push-before HEAD
           fi
 
+      # Documentation only. Commands, skills, prompt templates, agent
+      # instructions (AGENTS.md) and .github/ content are inputs to coding
+      # agents rather than prose, and are deliberately left unlinted so a
+      # documentation pass never reformats them. Add new documentation
+      # paths to the DOC_GLOBS list above.
+      - name: Verify the documentation globs match files
+        shell: bash
+        run: |
+          set -euo pipefail
+          shopt -s globstar nullglob
+
+          # Checked per glob, not on the total: one stale entry among several
+          # still leaves that part of the documentation unlinted, which is the
+          # failure #4526 was about.
+          count=0
+          empty=()
+          while IFS= read -r glob; do
+            [ -z "$glob" ] && continue
+            matched=0
+            for path in $glob; do
+              [ -f "$path" ] && matched=$((matched + 1))
+            done
+            # An array, not a string: nullglob is on, so re-expanding an
+            # unquoted list of unmatched globs would erase it.
+            [ "$matched" -eq 0 ] && empty+=("$glob")
+            count=$((count + matched))
+          done <<< "$DOC_GLOBS"
+
+          echo "documentation files matched: $count"
+          if [ ${#empty[@]} -gt 0 ]; then
+            for glob in "${empty[@]}"; do
+              echo "::error::markdownlint glob matches no files: $glob (see #4526)"
+            done
+            exit 1
+          fi
+
       - name: Run markdownlint-cli2
         uses: DavidAnson/markdownlint-cli2-action@21c1be1b93ad9ed58fa840aacc3f279cde2a72ff # v24.2.0
         with:
-          globs: |
-            '**/*.md'
-            !extensions/**/*.md
+          globs: ${{ env.DOC_GLOBS }}
 
   shellcheck:
     runs-on: ubuntu-latest

specify_cli-1.0.13/.github/workflows/stale.yml

@@ -0,0 +1,63 @@
+name: 'Close stale issues and PRs'
+
+on:
+  schedule:
+    - cron: '0 0 * * *' # Run daily at midnight UTC
+  workflow_dispatch: # Allow manual triggering
+
+permissions:
+  actions: write
+  issues: write
+  pull-requests: write
+
+jobs:
+  stale:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
+        with:
+          # Days of inactivity before an issue or PR becomes stale
+          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 had no activity for 60 days.
+            It will be closed in 30 days unless there is a substantive update. If the problem still applies,
+            please provide updated context such as whether it is still reproducible, the affected version or
+            environment, its current impact, and any new reproduction details. A comment that only states that
+            the issue is "still relevant" does not give maintainers enough information to reconsider it.
+          close-issue-message: >-
+            This issue has been automatically closed after 90 days without activity. To request reconsideration,
+            please provide updated reproduction details, the currently affected version or environment, and the
+            present impact. Ask a maintainer to reopen this issue if it is fundamentally the same problem. If the
+            scope or reproduction has materially changed, create a new issue, link this one, and explain what has
+            changed.
+          stale-issue-label: 'stale'
+
+          # Stale PR settings
+          stale-pr-message: >-
+            This pull request has been automatically marked as stale because it has had no activity for 60 days.
+            It will be closed in 30 days unless there is a substantive update. If you intend to continue, please
+            describe the current status, address or acknowledge outstanding feedback, and confirm whether the
+            branch can be updated and the change remains ready for review. A comment that only states that the
+            pull request is "still relevant" does not provide enough context for maintainers.
+          close-pr-message: >-
+            This pull request has been automatically closed after 90 days without activity. To request
+            reconsideration, please explain why the change is still needed, confirm that the implementation is
+            current and ready for review, and address any outstanding feedback or conflicts. Ask a maintainer to
+            reopen this pull request if the existing branch and approach remain valid. Otherwise, create a new pull
+            request, link this one, and explain what has changed.
+          stale-pr-label: 'stale'
+
+          # Exempt issues and PRs with these labels from being marked as stale
+          exempt-issue-labels: 'pinned,security'
+          exempt-pr-labels: 'pinned,security'
+
+          # Only issues or PRs with all of these labels are checked
+          # Leave empty to check all issues and PRs
+          any-of-labels: ''
+
+          # Operations per run (helps avoid rate limits)
+          operations-per-run: 250

specify_cli-1.0.13/AGENTS.md

@@ -0,0 +1,58 @@
+# AGENTS.md
+
+## About Spec Kit and Specify
+
+**GitHub Spec Kit** is a comprehensive toolkit for implementing Spec-Driven Development (SDD) - a methodology that emphasizes creating clear specifications before implementation. The toolkit includes templates, scripts, and workflows that guide development teams through a structured approach to building software.
+
+**Specify CLI** is the command-line interface that bootstraps projects with the Spec Kit framework. It sets up the necessary directory structures, templates, and AI agent integrations to support the Spec-Driven Development workflow.
+
+The toolkit supports multiple AI coding assistants, allowing teams to use their preferred tools while maintaining consistent project structure and development practices.
+
+## Adding or Updating CLI Commands
+
+Before adding, updating, or reorganizing Specify CLI commands, read
+[Specify CLI Command Architecture](design/cli.md). It defines command-module
+naming, private command phases, nested command groups, registration ownership,
+mirrored tests, and the rationale for making the CLI structure predictable for
+both humans and coding agents.
+
+## Adding or Updating Agent Integrations
+
+Before adding or changing AI agent integrations, read
+[Agent Integration Design](design/integration.md). It covers
+delivery routes, output formats, registration, and install/uninstall ownership.
+
+## Adding or Updating Workflow Steps
+
+Before adding or changing workflow step types, read
+[Workflow Step Design](design/workflow-step.md). It covers registration,
+validation, execution, resume, and installed step packages.
+
+## Testing Executable Behavior
+
+Before changing code or configuration that runs or controls execution without
+an LLM, read
+[Testing deterministic behavior](CONTRIBUTING.md#testing-deterministic-behavior).
+Behavioral changes need positive and negative coverage; bug fixes need
+before-and-after regression evidence.
+
+## Branches and Agent Contributions
+
+When creating a branch, follow [Branch naming](CONTRIBUTING.md#branch-naming).
+Before authoring commits, opening PRs, or posting review comments, read
+[Agent-authored Git and review activity](CONTRIBUTING.md#agent-authored-git-and-review-activity).
+Agent-authored commits and AI-generated PRs and comments each require their
+own disclosure; a PR-body disclosure alone does not cover later activity.
+
+## Other Contribution Guidance
+
+For contribution or repository-workflow questions not covered above, or when
+the applicable guidance is unclear, read [CONTRIBUTING.md](CONTRIBUTING.md)
+before acting.
+
+## Common Pitfalls
+
+- **Running tests against the wrong environment:** Run the suite inside this
+  worktree's own virtualenv (`uv sync --extra test` then
+  `.venv/bin/python -m pytest`). A bare `uv run pytest` can pick up an
+  editable install from another worktree and fail to import new subpackages.

{specify_cli-1.0.11 → specify_cli-1.0.13}/CHANGELOG.md

@@ -2,6 +2,56 @@
 
 <!-- insert new changelog below this comment -->
 
+## [1.0.13] - 2026-09-29
+
+### Changed
+
+- community: add Raaghu Spec Kit Azure DevOps extension to friends (#4782)
+- feat(extensions): add bundled `github` extension for taskstoissues (#4488)
+- fix(integrations): drop invalid --model/--output-format flags from Vibe dispatch (#4784)
+- Update Superpowers Implementation Bridge extension to v1.3.0 (#4783)
+- fix(workflows): evaluate parenthesised expressions (#4417)
+- fix(workflows): resolve negative list indices in expressions (#4416)
+- docs: explain how Spec Kit uses an agentic SDLC (#4774)
+- fix(copilot): detect copilot.exe on Windows instead of assuming copilot.cmd (#4758)
+- fix: keep non-ASCII text readable in merged JSON settings files (#4773)
+- Added openspec extension (#4765)
+- feat(integrations): add MiniMax Code (mcode) integration (#4644) (#4645)
+- docs(community): add Specstride to Community Friends (#4762)
+- docs: clarify feature directories may live outside the project root (#4739)
+- fix(scripts): honor SPECKIT_PYTHON override for preset manifest parsing (#4445)
+- chore: clarify stale issue and PR guidance (#4772)
+- Update OWASP LLM Threat Model extension to v2.1.2 (#4771)
+- docs: correct workflow publishing security-review claim, add catalog vetting notes (#4736)
+- [preset] Update Intake Sequencing Governance preset to v0.2.6 (#4761)
+- [extension] Add Test Validation extension to community catalog (#4760)
+- chore: release 1.0.12, begin 1.0.13.dev0 development (#4759)
+
+## [1.0.12] - 2026-09-25
+
+### Changed
+
+- fix(workflows): reject a multi-argument filter call in expressions (#3893)
+- feat(auth): add Bitbucket authentication provider (#4629)
+- Add Agentstandards bundle to community catalog (#4751)
+- docs: consolidate design guidance and contribution guidelines (#4752)
+- Add Agentstandards Task Gate preset to community catalog (#4749)
+- fix(alquimia): render `/speckit-<name>` invocations for the skills-only Alquimia agent (#4137)
+- [preset] Update Intake Review Governance preset to v0.2.3 (#4748)
+- refactor(presets): split domain internals into private modules (#4747)
+- chore(deps): bump the codeql-action group with 2 updates (#4742)
+- Add Agentstandards Architecture Council extension to community catalog (#4730)
+- fix(ci): make the markdownlint job lint files again (#4526) (#4584)
+- Update SpecAssay community bundle to v0.5.2 (#4737)
+- Update SpecAssay Check extension to v0.5.2 (#4735)
+- [preset] Update SpecAssay preset to v0.5.2 (#4717)
+- fix: sync integration manifest hashes after preset re-registration on upgrade (#4697)
+- [extension] Update OKF Knowledge Bundle Generator to v0.9.2 (#4700)
+- Update Intake Authoring Governance preset to v0.3.4 (#4716)
+- fix: eliminate TOCTOU races in catalog_fetch() for file:// and bare path URLs (#3910)
+- fix: add ValueError guard for timeout in _build_opencode_plugin (#3973)
+- chore: release 1.0.11, begin 1.0.12.dev0 development (#4723)
+
 ## [1.0.11] - 2026-09-24
 
 ### Changed

{specify_cli-1.0.11 → specify_cli-1.0.13}/CONTRIBUTING.md

@@ -38,7 +38,7 @@ On [GitHub Codespaces](https://github.com/features/codespaces) it's even simpler
 1. Fork and clone the repository
 1. Configure and install the dependencies: `uv sync --extra test`
 1. Make sure the CLI works on your machine: `uv run specify --help`
-1. Create a new branch: `git checkout -b <type>/<number>-<short-slug>` (see [Branch naming](#branch-naming) below)
+1. Create a new branch (see [Branch naming](#branch-naming) below)
 1. Make your change, add tests, and make sure everything still works
 1. Test the CLI functionality with a sample project if relevant
 1. Push to your fork and submit a pull request
@@ -55,7 +55,7 @@ Here are a few things you can do that will increase the likelihood of your pull
 - Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
 - Test your changes with the Spec-Driven Development workflow to ensure compatibility.
 
-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. Repository-owned `gh-aw` maintenance workflows do not require this confirmation.
+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 must follow the [agent-authored PR rules](#agent-authored-git-and-review-activity) before opening another pull request.
 
 ### Evidence gate
 
@@ -137,7 +137,9 @@ fix to a broken entry is still an update and needs the same validation. Always p
 
 ### 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:
+When an issue exists, name the branch `<type>/<issue-number>-<short-slug>`.
+For PR-only changes without an issue, use `<type>/<short-slug>` instead.
+Choose the prefix from:
 
 | Prefix | When to use | Example |
 |---|---|---|
@@ -147,7 +149,9 @@ We recommend naming branches as `<type>/<number>-<short-slug>`, where `<number>`
 | `community/` | Community catalog additions | `community/2492-add-mde-extension` |
 | `chore/` | Maintenance, tooling, CI | `chore/2366-editorconfig` |
 
-Including the issue or PR number makes branches traceable — especially useful since the project uses squash merges and `git branch --merged` won't detect merged branches. If you start with a PR (no issue), use the PR number once it's assigned.
+Put an existing issue number immediately after the prefix to make the branch
+traceable; do not add a PR number later for PR-only changes. Keep the slug
+short, descriptive, and kebab-case.
 
 ## Development workflow
 
@@ -179,6 +183,22 @@ When working on spec-kit:
 3. Test script functionality in the `scripts/` directory
 4. Ensure memory files (`memory/constitution.md`) are updated if major process changes are made
 
+### Testing deterministic behavior
+
+Behavioral changes to repository-maintained code or configuration that runs or
+controls execution without an LLM require tests for both intended behavior
+(positive cases) and relevant invalid inputs, failures, or prevented behavior
+(negative cases). This includes Python, shell, and PowerShell code in the CLI,
+core scripts, extensions, presets, and tooling; workflow step types; and
+execution wiring such as script selection, workflow shell steps, and CI `run:`
+steps. Existing tests count when they cover the changed behavior.
+
+Bug fixes also need a regression test that fails before the fix and passes
+afterward. If a baseline or an execution path cannot be tested automatically,
+explain the limitation and provide reproducible evidence for the affected
+success and failure paths. Prompt-only and other non-behavioral edits do not
+require invented tests.
+
 ### Recommended validation flow
 
 For the smoothest review experience, validate changes in this order:
@@ -278,7 +298,7 @@ Any change that affects a slash command's behavior requires manually testing tha
 
 Paste this into your PR:
 
-~~~markdown
+```markdown
 ## Manual test results
 
 **Agent**: [e.g., GitHub Copilot in VS Code]  |  **OS/Shell**: [e.g., macOS/zsh]
@@ -286,13 +306,13 @@ Paste this into your PR:
 | Command tested | Notes |
 |----------------|-------|
 | `/speckit.command` | |
-~~~
+```
 
 #### Determining which tests to run
 
 Copy this prompt into your agent. Include the agent's response (selected tests plus a brief explanation of the mapping) in your PR.
 
-~~~text
+```text
 Read CONTRIBUTING.md, then run `git diff --name-only main` to get my changed files.
 For each changed file, determine which slash commands it affects by reading
 the command templates in templates/commands/ to understand what each command
@@ -324,7 +344,7 @@ Number each test sequentially (T1, T2, ...). List prerequisite tests first.
 
 - T1: /speckit.command — (reason)
 - T2: /speckit.command — (reason)
-~~~
+```
 
 ## AI contributions in Spec Kit
 
@@ -346,6 +366,8 @@ That being said, if you are using any kind of AI assistance (e.g., agents, ChatG
 If your PR responses or comments are being generated by an AI, disclose that as well, naming the same agent, model(s), settings/mode, and extent.
 
 As an exception, trivial spacing or typo fixes don't need to be disclosed, so long as the changes are limited to small parts of the code or short phrases. The catalog-submission issue forms (extension, preset, and bundle submissions) feed content-neutral validation automation rather than code review, so they carry no disclosure field and are exempt from this requirement. Spec Kit's own bundled agentic workflows (the automated bug-fix and community-catalog prompts under `.github/workflows/`) are likewise exempt: they run as a fixed, known agent and open draft PRs for maintainer review, so their agent identity is inherent to the workflow rather than self-declared per contribution.
+The trivial-fix exception does not waive the disclosures below for agents acting
+on behalf of a contributor; the bundled workflows retain their exception.
 
 An example disclosure:
 
@@ -365,6 +387,39 @@ what extent, which in turn helps us judge whether our [`AGENTS.md`](./AGENTS.md)
 In a perfect world, AI assistance would produce equal or higher quality work than any human. That isn't the world we live in today, and in most cases
 where human supervision or expertise is not in the loop, it's generating code that cannot be reasonably maintained or evolved.
 
+### Agent-authored Git and review activity
+
+For an agent acting on behalf of a contributor, disclosure is continuous: the
+PR body, each agent-authored commit, and each AI-generated PR comment or reply
+must independently identify the agent's involvement. A PR-body disclosure does
+not cover later commits or review rounds.
+
+- **Before opening a PR:** Check whether the filing account already has three
+  open PRs in this repository. If so, explain that another submission may
+  receive lower review priority and obtain the filer's explicit permission.
+  Without it, including during autonomous operation, leave the work on a branch
+  and report that confirmation is required. Repository-owned `gh-aw` maintenance
+  workflows are exempt from this count check.
+- **For every agent-authored commit:** Include an `Assisted-by:` trailer naming
+  the actual agent and model and whether it acted `autonomous` or `supervised`,
+  for example, `Assisted-by: GitHub Copilot (model: Claude Opus 4.8, autonomous)`.
+  Use `model: unknown` only if the model genuinely cannot be determined. Use
+  `supervised` only if a human authored or line-by-line reviewed the change
+  before commit. Do not hide agent authorship behind the operator's git
+  identity or remove tool-generated `Co-authored-by:` trailers.
+- **For each AI-generated PR comment:** Identify the contributor on whose
+  behalf it is posted, the agent, model, settings/mode, and extent of AI
+  involvement. Restate this in every review-round summary, not just the PR
+  body. Post one top-level summary per round with the changes and commit SHA;
+  reply inline only for disagreement, deferral, or a non-obvious fix, and keep
+  those replies brief. Do not resolve conversations on a reviewer's behalf.
+  Avoid emoji, celebratory framing, checklist mirroring, and restating the
+  reviewer's comments. Re-request review once, after all feedback is addressed.
+
+Fast responses do not replace disclosure: do not post an unexplained "Done" or
+push an undisclosed fix moments after review. Do not claim personal human review
+or testing for an automated change; describe the automation truthfully.
+
 ### What we're looking for
 
 When submitting AI-assisted contributions, please ensure they include:

{specify_cli-1.0.11 → specify_cli-1.0.13}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.0.11
+Version: 1.0.13
 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.11 → specify_cli-1.0.13}/bundles/catalog.community.json

@@ -1,8 +1,31 @@
 {
   "schema_version": "1.0",
-  "updated_at": "2026-08-21T00:00:00Z",
+  "updated_at": "2026-09-25T00:00:00Z",
   "catalog_url": "https://raw.githubusercontent.com/github/spec-kit/main/bundles/catalog.community.json",
   "bundles": {
+    "agentstandards": {
+      "name": "Agentstandards Multi-Vendor Architecture",
+      "id": "agentstandards",
+      "version": "0.1.1",
+      "role": "architecture-governance",
+      "description": "Installs a Codex-orchestrated, multi-vendor architecture council, its hard task gate, and the supporting Spec Kit workflow.",
+      "author": "bbjwz",
+      "license": "MIT",
+      "download_url": "https://github.com/bbjwz/agentstandards/releases/download/v0.1.1/agentstandards-bundle-0.1.1.zip",
+      "sha256": "0306cdc780f4107e6702cd25680afede8acea866dfbb0ba81f9ea9c8f960a9dc",
+      "repository": "https://github.com/bbjwz/agentstandards",
+      "requires": {
+        "speckit_version": ">=1.0.8,<2.0.0"
+      },
+      "provides": {
+        "extensions": 1,
+        "presets": 1,
+        "steps": 0,
+        "workflows": 1
+      },
+      "tags": ["architecture", "governance", "multi-vendor", "codex"],
+      "verified": false
+    },
     "sicario-spec": {
       "name": "SicarioSpec Security & Governance Bundle",
       "id": "sicario-spec",
@@ -34,15 +57,16 @@
     "specassay": {
       "name": "SpecAssay",
       "id": "specassay",
-      "version": "0.4.12",
+      "version": "0.5.2",
       "role": "developer",
       "description": "Durable-ID promotion for stock Spec Kit: templates, Gate 2 refusal, and trace-manifest emission.",
       "author": "Rik Dryfoos",
       "license": "MIT",
-      "download_url": "https://github.com/rdryfoos/specassay/releases/download/v0.4.12/specassay-0.4.12.zip",
+      "download_url": "https://github.com/rdryfoos/specassay/releases/download/v0.5.2/specassay-0.5.2.zip",
+      "sha256": "a9acd0848132bee975be7ca6759a531ff02b736c99a98b1bc4e7d8da90da7c82",
       "repository": "https://github.com/rdryfoos/specassay",
       "requires": {
-        "speckit_version": ">=0.14.0"
+        "speckit_version": ">=0.14.0,<2.0.0"
       },
       "provides": {
         "extensions": 1,

{specify_cli-1.0.11 → specify_cli-1.0.13}/design/cli.md

@@ -249,6 +249,25 @@ the domain has the same name as that CLI namespace. The nested directory is
 reserved for `test_command_<name>.py` suites that exercise its actual
 subcommands.
 
+When a domain implementation is split into private modules, mirror those
+boundaries in its tests, dropping the source module's leading underscore:
+
+| Preset implementation | Mirrored test under `tests/specify_cli/presets/` |
+| --- | --- |
+| `_manifest.py` | `test_manifest.py` |
+| `_registry.py` | `test_registry.py` |
+| `_catalog.py` | `test_catalog.py` |
+| `_resolver.py` | `test_resolver.py` |
+| `_manager.py` | `test_manager.py` |
+| `_manager_commands.py` | `test_manager_commands.py` |
+| `_manager_skills.py` | `test_manager_skills.py` |
+
+`test_manager_commands.py` exercises domain command-artifact behavior, not a
+registered CLI handler. The `test_command_*.py` suites continue to cover the
+CLI surface. `test_catalog.py` belongs at the parent preset package level;
+`catalog/test_command_*.py` covers the nested catalog CLI. Package export
+compatibility is covered separately by `test_domain_exports.py`.
+
 Not every test is a command test, even when it belongs in the mirrored package
 tree:
 
@@ -264,6 +283,10 @@ tree:
 
 Moving tests must preserve coverage rather than duplicating it. Run both the
 new command-focused suites and the legacy suites from which tests were moved.
+For domain splits, also run all new domain suites and any remaining cross-domain
+tests in the legacy file. Compare full-suite collection before and after the
+move: the count must not decrease, and every existing parametrized test case
+must remain represented. A matching total alone does not prove preservation.
 
 ## Reference layout
 

specify_cli-1.0.13/design/integration.md

@@ -0,0 +1,108 @@
+# Agent Integration Design
+
+Integrations adapt the shared Spec Kit workflows to an AI coding agent. Their
+**availability** (built-in, generic, or catalog-only) is separate from their
+**output format** (commands, recipes, skills, or a custom layout). The Python
+integration registry owns installation behavior; catalogs provide discovery,
+not executable integration implementations.
+
+## Availability
+
+| Route | What ships | How users get it |
+|---|---|---|
+| Built-in | A registered class under `src/specify_cli/integrations/` and, for discovery, an entry in `integrations/catalog.json` | `specify init my-project --integration copilot` or, in an initialized project, `specify integration install copilot` |
+| Generic | The registered `generic` integration, with a user-supplied `--commands-dir` and optional `--skills` | `specify init my-project --integration generic --integration-options="--commands-dir .agent/commands"` |
+| Community | Metadata in `integrations/catalog.community.json` pointing to an external project | Discover with `specify integration list --catalog` or `search`; obtain and vet it from its source |
+
+The default community catalog is discovery-only. A catalog entry (including
+one in a custom catalog) does **not** register a Python integration or make
+`specify integration install <key>` work: installation resolves keys through
+`INTEGRATION_REGISTRY`. See [catalog contribution guidance](../integrations/CONTRIBUTING.md)
+for descriptor and submission details.
+
+## Built-in contract
+
+Each built-in agent has one Python-safe subpackage: `copilot` lives in
+`src/specify_cli/integrations/copilot/` and exposes `CopilotIntegration`.
+Hyphenated keys use underscores in package names. Its class declares:
+
+- `key`: unique user-facing identifier. CLI-backed integrations normally use
+  the executable name: tool checks use the key and runtime dispatch defaults
+  to it. Agents with a different executable must handle both paths explicitly;
+  IDE-only agents use their canonical identifier.
+- `config`: agent name, folder, commands subdirectory, install URL, and
+  `requires_cli`.
+- `registrar_config`: output directory, format, argument placeholder, and
+  file extension.
+
+Import and `_register()` the class in `src/specify_cli/integrations/__init__.py`
+(both lists alphabetically). This registry is the source of built-in Python
+integration behavior. If the agent supports non-interactive workflows, implement
+`build_exec_args()` with the full base signature; `options()` declares
+install-time `--integration-options`, not per-workflow runtime options.
+Agent-specific native events can be declared on the integration. Set
+`multi_install_safe = True` only for a static, non-overlapping agent root and
+command directory; shared dynamic paths are not safe by default.
+
+## Output flavors
+
+Choose the smallest base class that matches the agent's native format. The
+format bases render shared `templates/commands/*.md`; `IntegrationBase.setup()`
+copies templates raw unless overridden. Paths below are relative to each
+agent's configured root.
+
+| Flavor | Base class | Typical output | Arguments |
+|---|---|---|---|
+| Markdown commands | `MarkdownIntegration` | `commands/speckit.plan.md` | `$ARGUMENTS` |
+| TOML commands | `TomlIntegration` | `commands/speckit.plan.toml` | `{{args}}` |
+| YAML recipes | `YamlIntegration` | `recipes/speckit.plan.yaml` | `{{args}}` |
+| Agent skills | `SkillsIntegration` | `skills/speckit-plan/SKILL.md` | `$ARGUMENTS` |
+| Nonstandard or dual-mode | `IntegrationBase` or a targeted override of a format base | Agent-specific files, companions, or settings | Agent-specific |
+
+`registrar_config["args"]` selects the installed argument syntax;
+`command_filename()` and `setup()` are override points when the native layout
+demands them. Keep mode selection, invocation spelling, and registration in
+sync. Agent-specific layouts and options belong in the integration code and
+the [supported-integrations reference](../docs/reference/integrations.md).
+
+Core templates that call scripts declare `sh`, `ps`, and `py` commands in
+`scripts:` frontmatter; template processing replaces `{SCRIPT}` with the
+selected variant. `py` is opt-in; non-interactive init defaults to `sh` on
+POSIX or `ps` on Windows. Maintain equivalent stdout behavior across all three.
+Bundled extension commands do not yet use this core-template script routing.
+`__AGENT__` and command references are resolved during rendering, not by
+adding per-agent wrapper scripts.
+
+## Ownership and lifecycle
+
+An installation records its files and SHA-256 hashes in
+`.specify/integrations/<key>.manifest.json`. Custom `setup()` code must track
+files it creates via the manifest (`record_file()` or the base class's
+write-and-record helpers). Do not track a pre-existing user file merely because
+you merged settings into it: unchanged tracked files are deleted on uninstall.
+`teardown()` preserves modified tracked files by default; `--force` can remove
+them. Keep agent-specific settings and events consistent with that lifecycle.
+
+The integration does **not** own agent context files such as `AGENTS.md` or
+`CLAUDE.md`. The opt-in `extensions/agent-context/` owns their defaults,
+configuration, and managed sections; do not add `context_file` fields or
+context-file handling to the CLI. `specify init` does not enable the extension
+implicitly. Extensions and presets register command or skill overrides for the
+current default integration, not every installed integration.
+
+## Adding an agent
+
+1. Run `specify integration scaffold my-agent --type markdown` from this
+   repository (`toml`, `yaml`, and `skills` are also supported), or start with
+   a custom class only when necessary.
+2. Review the generated `config` and `registrar_config`; register the class
+   alphabetically and add a matching entry to `integrations/catalog.json`.
+3. Add focused coverage in `tests/integrations/test_integration_<package_dir>.py`
+   for metadata, generated output, installation, and uninstall (including
+   preservation of edited files where applicable).
+4. Exercise `specify init my-project --integration <key>` and the install/uninstall
+   lifecycle; update the [supported agents](../docs/reference/integrations.md)
+   and devcontainer setup if the agent needs additional tooling.
+
+The scaffold creates a package and test skeleton, **not** registry or catalog
+entries. Prefer existing bases and shared processing over copied setup loops.