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

{specify_cli-1.0.11 → specify_cli-1.0.12}/.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.12}/.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.12/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.12}/CHANGELOG.md

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.0.11
+Version: 1.0.12
 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.12}/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.12}/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.12/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.

specify_cli-1.0.12/design/workflow-step.md

@@ -0,0 +1,64 @@
+# Workflow Step Design
+
+A workflow step type defines what a `type:` in workflow YAML does. This is an
+extension point of the workflow engine, distinct from an agent integration:
+integrations dispatch work to an agent; steps validate and execute workflow
+behavior. For the overall engine, see
+[Workflow System Architecture](../workflows/ARCHITECTURE.md); for YAML usage,
+see [Workflows](../docs/reference/workflows.md).
+
+## Delivery and registration
+
+| Route | Source | Registration |
+|---|---|---|
+| Built-in | `src/specify_cli/workflows/steps/<package>/__init__.py` | Explicit import and `_register_step()` in `src/specify_cli/workflows/__init__.py` |
+| Installed | Package under `.specify/workflows/steps/<id>/`, containing `step.yml` and `__init__.py` | `load_custom_steps(project_root)` loads a matching `StepBase` subclass at workflow run/resume |
+
+`STEP_REGISTRY` maps each `type_key` to a single step instance. Built-in keys
+are snapshotted in `BUILTIN_STEP_TYPES` before project steps are loaded; do not
+infer built-in status from the mutable registry. Installed packages can be
+found through step catalogs and added with `specify workflow step add <id>`.
+The default community catalog is discovery-only, not an install or trust
+endorsement. Review external step code before installing it: loading a package
+imports and executes its Python module.
+
+## Step contract
+
+Subclass `StepBase` from `src/specify_cli/workflows/base.py`, set `type_key`
+to the workflow YAML `type`, and implement
+`execute(config: dict[str, Any], context: StepContext) -> StepResult`.
+Override `validate(config)` for step-specific errors; the base validator
+requires an `id`. Omitting `type` in YAML selects the built-in `command` step.
+
+`StepContext` supplies inputs, previous step results, workflow defaults, run
+and project paths, and iteration/resume context. Return a `StepResult` with a
+`StepStatus`, an output mapping, and an error message on failure. The engine
+records the result for later `{{ steps.<id>.output.* }}` expressions and
+persists run state. `PAUSED` stops for resume; `FAILED` normally stops the run
+unless `continue_on_error: true` is set (an explicit abort always stops).
+`next_steps` supplies nested steps for control flow.
+
+The engine calls `validate()` during workflow validation but does not
+automatically validate a definition passed to `execute()`. Guard invalid
+configurations in `execute()` too, returning a failed result rather than a
+successful default or an unhandled exception. Resume restarts the current
+top-level step; a pause inside nested steps re-runs their parent and nested
+body. Design side effects accordingly.
+
+The registry holds one shared instance per type. Concurrent `fan-out` can
+invoke that instance from multiple threads: keep execution stateless and
+thread-safe, with per-run data in `config` and `context`, not on `self`.
+
+## Adding a step type
+
+1. Implement the step in its own `steps/<package>/` subpackage and register
+   it explicitly with a unique `type_key`. For an external package, provide
+   `step.yml` with a matching `step.type_key` and a matching subclass in
+   `__init__.py`; catalog discovery alone does not register the code.
+2. Test valid and invalid configurations, status/output/error behavior, and
+   resume or nested/concurrent execution when relevant. Registry and engine
+   coverage lives in `tests/test_workflows.py`; focused step suites may live
+   under `tests/workflows/`.
+3. Update the [workflow reference](../docs/reference/workflows.md) when a
+   built-in step changes the YAML users can write. Keep agent-specific CLI
+   dispatch in integrations rather than duplicating it in step types.

{specify_cli-1.0.11 → specify_cli-1.0.12}/docs/community/bundles.md

@@ -9,6 +9,7 @@ Accepted community bundle entries are published in [`bundles/catalog.community.j
 
 | Bundle | Purpose | Role or team | Provides | Required catalogs | URL |
 |--------|---------|--------------|----------|-------------------|-----|
+| Agentstandards Multi-Vendor Architecture | Installs a Codex-orchestrated, multi-vendor architecture council, its hard task gate, and the supporting Spec Kit workflow. | `architecture-governance` | 1 extension, 1 preset, 1 workflow | Documented | [agentstandards](https://github.com/bbjwz/agentstandards) |
 | SicarioSpec Security & Governance Bundle | Secure-by-default governance bundle for GitHub Spec Kit. Enforces data classification, threat modeling, and code-owned verification gates. | `security-engineer` | 1 extension, 11 presets | Documented | [sicario-spec](https://github.com/dfirs1car1o/sicario-spec) |
 | SpecAssay | Durable-ID promotion for stock Spec Kit: templates, Gate 2 refusal, and trace-manifest emission. | `developer` | 1 extension, 1 preset | Documented | [specassay](https://github.com/rdryfoos/specassay) |
 

{specify_cli-1.0.11 → specify_cli-1.0.12}/docs/community/extensions.md

@@ -32,6 +32,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | 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 Pre-Pay Audit — Grade an endpoint before your agent pays it | Audit a paid API before money moves: grade the endpoint's 402 terms, see what the live market actually charges, and confirm the wallet can complete the payment right now. | `visibility` | Read-only | [spec-kit-prepay-audit](https://github.com/shawnhvac/spec-kit-prepay-audit) |
 | 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) |
+| Agentstandards Architecture Council | Run a bounded, multi-vendor architecture council between Spec Kit planning and task generation. | `process` | Read+Write | [agentstandards](https://github.com/bbjwz/agentstandards) |
 | 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) |
@@ -110,7 +111,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 rationale and parking what it cannot verify as open questions | `docs` | Read+Write | [speckit_okf](https://github.com/alexcpn/speckit_okf) |
+| OKF Knowledge Bundle Generator | Generates and maintains an Open Knowledge Format (OKF v0.1) knowledge bundle from a source-code repository. Mines git history for the rationale behind the code, parks what it cannot establish as open questions rather than guessing, and verifies that the bundle's claims are actually supported by the repository. | `docs` | Read+Write | [catalogify](https://github.com/alexcpn/catalogify) |
 | 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) |
 | OpenUP Governed Lifecycle | Adds the OpenUP lifecycle to Spec Kit: phases, iterations, a seven-level WBS, an executable risk register, bi-directional traceability, and machine-checkable milestone gates. | `process` | Read+Write | [specup](https://github.com/anvigo12/specup) |
 | 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) |
@@ -165,7 +166,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Spec Trace | Build a requirement → test traceability matrix from spec.md and the test suite — surface untested requirements and orphan tests | `code` | Read+Write | [spec-kit-trace](https://github.com/Quratulain-bilal/spec-kit-trace) |
 | Spec Validate | Comprehension validation, review gating, and approval state for spec-kit artifacts — staged quizzes, peer review SLA, and a hard gate before /speckit.implement | `process` | Read+Write | [spec-kit-spec-validate](https://github.com/aeltayeb/spec-kit-spec-validate) |
 | Spec2Cloud | Spec-driven workflow tuned for shipping to Azure | `process` | Read+Write | [spec2cloud](https://github.com/Azure-Samples/Spec2Cloud) |
-| SpecAssay Check | Gate 2 refuses silent gaps and emits a trace-manifest (trace-manifest.json). | `visibility` | Read+Write | [specassay](https://github.com/rdryfoos/specassay) |
+| SpecAssay Check | Gate 2 refuses silent gaps and emits a trace-manifest (`trace-manifest.json`). | `visibility` | Read+Write | [specassay](https://github.com/rdryfoos/specassay) |
 | SpecJudge — right-size the model before you implement | Recommends the model that fits your tasks, citing the spec fragment behind every level. | `process` | Read-only | [SpecJudge](https://github.com/JoaquinRuiz/SpecJudge) |
 | SpecKit Companion | Live spec-driven progress — lifecycle capture, status, resume, living specs, and composable commands with hooks and recipes | `process` | Read+Write | [speckit-companion](https://github.com/alfredoperez/speckit-companion) |
 | SpecKit Grill Me | Exhaustively clarify specifications and optionally sync canonical domain knowledge | `process` | Read+Write | [speckit-grill-me](https://github.com/yoshi1220/speckit-grill-me) |