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

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

@@ -2,6 +2,31 @@
 
 <!-- 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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.0.12
+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.12 → specify_cli-1.0.13}/docs/README.md

@@ -28,6 +28,7 @@ To build the documentation locally:
 - `toc.yml` - Table of contents configuration
 - `installation.md` - Installation guide
 - `quickstart.md` - Spec-Driven Development walkthrough
+- `guides/agentic-sdlc.md` - How Spec Kit applies agentic and conventional SDLC practices to itself
 - `guides/bugfix.md` - Bug-fixing walkthrough
 - `guides/assessment.md` - Idea assessment walkthrough
 - `guides/customization.md` - Choosing and combining customization building blocks

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

@@ -113,10 +113,11 @@ The following community-contributed extensions are available in [`catalog.commun
 | .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. 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) |
+| OpenSpec | Adds a spec-driven change-management workflow (propose → implement → verify → archive) to Spec Kit projects, keeping specs, designs, and code in sync | `process` | Read+Write | [spec-kit-openspec](https://github.com/aaronrsun/spec-kit-openspec) |
 | 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) |
 | 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) |
-| OWASP LLM Threat Model | OWASP Top 10 for LLM Applications 2025 threat analysis on agent artifacts | `code` | Read-only | [spec-kit-threatmodel](https://github.com/NaviaSamal/spec-kit-threatmodel) |
+| OWASP LLM Threat Model | OWASP Top 10 for LLM Applications 2026 threat analysis on agent artifacts | `code` | Read-only | [spec-kit-threatmodel](https://github.com/NaviaSamal/spec-kit-threatmodel) |
 | PatchWarden Evidence Pack | Map Spec Kit tasks into a guarded PatchWarden Goal and export bounded, traceable evidence for an accepted lineage. | `process` | Read+Write | [spec-kit-patchwarden](https://github.com/jiezeng2004-design/spec-kit-patchwarden) |
 | Plan Review Gate | Require spec.md and plan.md to be merged via MR/PR before allowing task generation | `process` | Read-only | [spec-kit-plan-review-gate](https://github.com/luno/spec-kit-plan-review-gate) |
 | PR Bridge | Auto-generate pull request descriptions, checklists, and summaries from spec artifacts | `process` | Read-only | [spec-kit-pr-bridge-](https://github.com/Quratulain-bilal/spec-kit-pr-bridge-) |
@@ -175,13 +176,14 @@ The following community-contributed extensions are available in [`catalog.commun
 | Staff Review Extension | Staff-engineer-level code review that validates implementation against spec, checks security, performance, and test coverage | `code` | Read-only | [spec-kit-staff-review](https://github.com/arunt14/spec-kit-staff-review) |
 | Status Report | Project status, feature progress, and next-action recommendations for spec-driven workflows | `visibility` | Read+Write | [Open-Agent-Tools/spec-kit-status](https://github.com/Open-Agent-Tools/spec-kit-status) |
 | Superpowers Bridge | Bridges selected Superpowers disciplines into Spec Kit as evidence-first trust gates for agent workflows. | `process` | Read+Write | [superpowers-bridge](https://github.com/RbBtSn0w/spec-kit-extensions/tree/main/superpowers-bridge) |
-| Superpowers Implementation Bridge | Thin orchestrator between Spec Kit (design) and Superpowers (implementation). Cross-agent. | `process` | Read+Write | [speckit-superpowers-bridge](https://github.com/lihan3238/speckit-superpowers-bridge) |
+| Superpowers Implementation Bridge | Thin orchestrator between Spec Kit design artifacts and Superpowers implementation discipline. Cross-agent; verified for Codex and Claude Code. | `process` | Read+Write | [speckit-superpowers-bridge](https://github.com/lihan3238/speckit-superpowers-bridge) |
 | Superspec | Bridges spec-kit with obra/superpowers (brainstorming, TDD, subagent, code-review) into a unified, resumable workflow with graceful degradation and session progress tracking | `process` | Read+Write | [superspec](https://github.com/WangX0111/superspec) |
 | Taco Review | Packages Spec Kit features for human review and syncs edits and comments back. | `integration` | Read+Write | [taco](https://github.com/Arcadia822/taco) |
 | Tasks to GitHub Project | Publish and synchronize Spec Kit tasks as cards on a GitHub Project (v2) kanban board, with priority and status sync between spec.md/tasks.md and the board. | `integration` | Read+Write | [spec-kit-tasks-to-project](https://github.com/mancioshell/spec-kit-tasks-to-project) |
 | TDD Extension | Drives spec-kit implementation with tests: a language-agnostic red-green-refactor loop with a per-feature test list, recorded red and green evidence, and mutation-checked test strength. | `process` | Read+Write | [spec-kit-tdd](https://github.com/d0whc3r/spec-kit-tdd) |
 | Team Assign | Assign tasks.md items to human engineers, split into subtasks, and generate a per-engineer workboard | `process` | Read+Write | [spec-kit-team-assign](https://github.com/tarunkumarbhati/spec-kit-team-assign) |
 | Test Coverage Drift Control | Generate incremental coverage drift reports and planned remediation tasks after implementation | `code` | Read+Write | [spec-kit-test-coverage-drift-control](https://github.com/benizzio/spec-kit-test-coverage-drift-control) |
+| Test Validation | Validate acceptance scenarios and run CSV-driven E2E tests against a live app via Playwright | `process` | Read+Write | [speckit-test-validate](https://github.com/andstepanuk/speckit-test-validate) |
 | ThreatSpec | STRIDE and AI/ML threat modeling with threat-to-test traceability and security convergence | `process` | Read+Write | [spec-kit-threatspec](https://github.com/hupe1980/spec-kit-threatspec) |
 | Time Machine | Retroactively apply the full SDD workflow to existing codebases — analyse, spec, and ship feature-by-feature | `process` | Read+Write | [spec-kit-time-machine](https://github.com/teeyo/spec-kit-time-machine) |
 | TinySpec | Lightweight single-file workflow for small tasks — skip the heavy multi-step SDD process | `process` | Read+Write | [spec-kit-tinyspec](https://github.com/Quratulain-bilal/spec-kit-tinyspec) |

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/community/friends.md

@@ -20,3 +20,7 @@ Community projects that extend, visualize, or build on Spec Kit:
 - **[spec-kit-copilot](https://github.com/github/spec-kit-copilot)** — *First-party GitHub project.* A GitHub Copilot **skills plugin** that exposes the Spec Kit `specify` CLI to the Copilot agent in both the Copilot CLI and the GitHub Copilot app. It provides a focused skill per `specify` command group — setup, init, check, extensions, presets, bundles, workflows, workflow steps, and self-upgrade — so you can navigate and drive the entire Spec Kit ecosystem through natural language, letting Copilot decide when and how to run the right `specify` commands on your behalf.
 
 - **[Spec Kit Workflow Cockpit](https://github.com/markuswondrak/spec-kit-workflow-cockpit)** — A terminal control panel for running Spec Kit workflows locally. It replaces the fragmented CLI flow with a single live view: see the whole workflow at a glance, follow progress node by node, read and edit feature documents at human review gates without leaving the terminal, and make gate decisions from clearly presented options with confirmation. It also provides a `cockpit-run-context` skill that connects your interactive coding session directly to the current workflow run.
+
+- **[Specstride](https://github.com/mairp/specstride)** — A standalone implementation orchestrator that consumes a Spec Kit feature's `tasks.md` and uses its `spec.md`, `plan.md`, and contracts as read-only context. It runs a coding agent (Claude Code, Codex, or a local model) through the task phases one at a time. Each phase advances only when a separate LLM critic approves its evidence against the acceptance criteria and the code. Stuck phases get a diagnostician and a narrowed retry. An opt-in loop learns per-phase settings from run telemetry and reverts any change that makes things worse.
+
+- **[Raaghu Spec Kit](https://marketplace.visualstudio.com/items?itemName=Waiin.raaghu-speckit)** — Raaghu Spec Kit brings specification-driven development into Azure DevOps. PMs, BAs, and QAs can generate, review, and manage structured specs, delivery plans, task breakdowns, and quality checklists — then create and refine Azure Boards work items — all from a guided AI workspace inside your project. Works with Azure DevOps Services and Azure DevOps Server (on-premises).

specify_cli-1.0.13/docs/guides/agentic-sdlc.md

@@ -0,0 +1,285 @@
+# How Spec Kit Develops Spec Kit: An Agentic SDLC
+
+Spec Kit's own development combines agentic work with conventional software
+delivery. Agents assess feature requests, help develop substantial changes,
+and investigate reported bugs. The project also uses Spec Kit itself where
+its processes fit, while deterministic tests and releases remain ordinary
+GitHub Actions and maintainers make the decisions to proceed or merge.
+
+Public workflows and a historical feature provide the evidence for this case
+study. They show different paths through the project's SDLC, including where
+the project uses Spec Kit itself.
+
+## The project's software development life cycle
+
+The traditional stages locate the project's practices across its SDLC.
+
+```mermaid
+flowchart LR
+    P["Planning"] --> Q["Requirements"] --> D["Design"] --> I["Development"]
+    I --> T["Testing"] --> R["Deployment"] --> M["Maintenance"]
+```
+
+These stages are a map, not a required sequence. Work can begin wherever
+its starting material and goal call for it: a feature request in planning,
+an existing change in testing, or a bug report in maintenance. Stages can
+overlap, repeat, or be skipped; one feature issue can feed an assessment,
+record requirements, and carry design discussion. The arrows show one
+familiar path, not mandatory transitions between SDLC stages.
+Feedback from maintenance can inform the next planning cycle.
+
+## Who does the work
+
+These modes illustrate how work gets done here; they are not an exhaustive
+taxonomy or inventory of activities. A stage can combine them.
+
+**Regular automation.** Scripts and bots follow predefined rules to run
+checks, propose dependency updates, and publish releases. They do not
+interpret feature requests or choose designs.
+
+**Agent automation.** A coding agent interprets context and produces an
+assessment, SDD artifacts, a proposed change, or a test report. It may run
+through a contributor-invoked Spec Kit command, a contributor's own agent,
+or a label-triggered repository workflow. Running an agent on GitHub
+Actions does not make its reasoning a deterministic script.
+
+A star (★) marks agentic work: before prose paragraphs and after
+timeline items. A person (👤) highlights human contributions in the
+stage narratives, including work done with an agent's help.
+
+**Human work.** People can frame issues, discuss approaches, write or revise
+changes, and review evidence, with or without an agent's help. Maintainers
+apply labels to start repository workflows and decide whether to proceed
+or merge. Those handoffs are human decisions, not evidence that people
+authored every assessment, specification, fix, or test report.
+
+## How the project works at each stage
+
+### 1. Planning: assess feature requests
+
+A feature can enter planning through the
+[feature request form](https://github.com/github/spec-kit/blob/main/.github/ISSUE_TEMPLATE/feature_request.yml).
+It asks for the problem, proposed solution, alternatives, component, and use
+cases. The resulting issue starts with `needs-triage`; filing it does not
+automatically launch an agent.
+
+★ When a feature request is labeled for assessment, the
+[feature-assess agentic workflow](https://github.com/github/spec-kit/blob/main/.github/workflows/feature-assess.md)
+provisions the Specify CLI from the checkout, installs Spec Kit's bundled
+[`assess` extension](assessment.md), and follows its intake, research, define,
+shape, and decide stages. The agent posts its evidence and a `go`,
+`needs-clarification`, or `kill` verdict to the issue. **This is an agentic
+workflow using Spec Kit itself.**
+
+👤 Contributors frame the request; maintainers decide whether to
+initiate assessment and how to act on its verdict. A `go` finding informs
+that planning decision; it does not automatically open a feature PR or
+start SDD.
+
+### 2. Requirements: record the intent in issues or specs
+
+👤 Contributors can record early requirements in the same feature issue
+through its problem statement, use cases, and acceptance criteria, then
+clarify or revise the intent during discussion. For a bounded change, that
+may be enough; it does not have to become an SDD `spec.md`.
+
+★ For substantial changes, contributors can instead expand the requirements
+with Spec Kit's core SDD commands against the project's constitution. Spec Kit
+used this process on itself in the
+[historical bundler work](https://github.com/github/spec-kit/commit/3fd1e54d4b237af6124bb967e2eae24c93685a89):
+the commit contains a constitution and feature specification for the
+`specify bundle` command. This is evidence of **SDD dogfooding for that
+feature**; the bundler work is distinct from the current `feature-assess`
+workflow. The
+[contribution guide](https://github.com/github/spec-kit/blob/main/CONTRIBUTING.md#does-spec-kit-use-spec-kit)
+asks contributors to test relevant changes with SDD while allowing small fixes
+to use the normal issue and PR process. Generated `specs/` artifacts are
+normally gitignored; the linked commit preserves a historical snapshot.
+
+### 3. Design: choose an approach at the right scale
+
+👤 The feature form's proposed solution and alternatives can seed a
+design discussion; contributors and maintainers can refine the approach
+during PR review. A separate SDD plan is not required for every issue.
+Larger changes need prior discussion and agreement with maintainers, as the
+[contribution guide](https://github.com/github/spec-kit/blob/main/CONTRIBUTING.md#submitting-a-pull-request)
+explains. When decisions should remain useful across changes, the repository
+keeps [CLI](https://github.com/github/spec-kit/blob/main/design/cli.md),
+[integration](https://github.com/github/spec-kit/blob/main/design/integration.md),
+and [workflow-step](https://github.com/github/spec-kit/blob/main/design/workflow-step.md)
+design documents.
+
+★ The [bundler SDD snapshot](https://github.com/github/spec-kit/commit/3fd1e54d4b237af6124bb967e2eae24c93685a89)
+illustrates the deeper path: its plan, research, data model, contracts, and
+tasks made the design actionable through `/speckit.plan` and
+`/speckit.tasks`. This shows where Spec Kit itself was used without
+presenting that level of detail as the default for every change.
+
+### 4. Development: make reviewable changes
+
+The [bundler implementation](https://github.com/github/spec-kit/pull/3070)
+added `specify bundle` after the recorded SDD work. This is a concrete
+specification-led feature in the project. Other bounded changes use the
+ordinary issue, PR, review, and test process.
+
+👤 Contributors can implement and revise changes directly or with an
+agent's help. Maintainers review the resulting PR and its evidence, even
+when an agent produced the proposed change.
+
+★ Contributors can use their own agents, independently of the repository's
+workflows. Because that work may not be visible in a diff, the
+[contribution policy](https://github.com/github/spec-kit/blob/main/CONTRIBUTING.md#ai-contributions-in-spec-kit)
+requires disclosure of the tool, model, settings or mode, and extent of AI
+assistance. Agent-authored commits and comments need their own attribution;
+the known bug-fix and community-catalog workflows are exempt because their
+agent identity is inherent. Disclosure provides provenance, not a lower
+evidence or review bar.
+
+### 5. Testing: verify both intent and behavior
+
+★ The bundler work includes a
+[convergence pass](https://github.com/github/spec-kit/commit/de1c8ce6765f07cd1c4728a251b95adbfa3a8d07)
+that appended a missing task. This is one example of Spec Kit's SDD process
+checking implementation against intent rather than treating the first pass
+as complete. The
+[bug-test workflow](https://github.com/github/spec-kit/blob/main/.github/workflows/bug-test.md)
+uses an agent to select relevant tests, but the test commands themselves
+still run deterministically.
+
+Separately, conventional GitHub Actions run
+[Python tests and Ruff](https://github.com/github/spec-kit/blob/main/.github/workflows/test.yml),
+[Markdown linting for documentation and ShellCheck for shell scripts](https://github.com/github/spec-kit/blob/main/.github/workflows/lint.yml),
+and [CodeQL](https://github.com/github/spec-kit/blob/main/.github/workflows/codeql.yml)
+on PRs and pushes to `main`. Agentic convergence complements those
+independent checks.
+
+👤 Contributors supply tests and reproduction evidence for changes;
+maintainers assess whether the patch and evidence address the stated need,
+not just whether the checks passed.
+
+### 6. Deployment: publish without an agent
+
+The Spec Kit repository uses regular GitHub Actions for delivery. The
+[manually dispatched release trigger](https://github.com/github/spec-kit/blob/main/.github/workflows/release-trigger.yml)
+sets the version, creates a tag, and opens a release PR. The tag triggers a
+conventional
+[GitHub Release](https://github.com/github/spec-kit/blob/main/.github/workflows/release.yml).
+A separately dispatched workflow
+[builds and publishes to PyPI](https://github.com/github/spec-kit/blob/main/.github/workflows/publish-pypi.yml);
+a `docs/` change on `main` triggers
+[DocFX deployment](https://github.com/github/spec-kit/blob/main/.github/workflows/docs.yml).
+These conventional Actions handle deterministic delivery without an agent
+or a Spec Kit command.
+
+👤 Maintainers choose when to start a release and whether to specify
+a version rather than use the automatic patch increment. They later dispatch
+PyPI publishing for that tag and review the release PR.
+
+### 7. Maintenance: investigate, repair, and learn
+
+👤 Reporters supply observed and expected behavior and reproduction
+steps through the
+[bug report form](https://github.com/github/spec-kit/blob/main/.github/ISSUE_TEMPLATE/bug_report.yml).
+Maintainers triage the report, choose when to request each agentic step,
+and review the proposed fix and test evidence before merging. Reports can
+arise before or after release; a newly discovered need can feed the next
+planning cycle instead of being folded into a repair.
+
+★ The repository uses separate
+[bug-assess](https://github.com/github/spec-kit/blob/main/.github/workflows/bug-assess.md),
+[bug-fix](https://github.com/github/spec-kit/blob/main/.github/workflows/bug-fix.md),
+and [bug-test](https://github.com/github/spec-kit/blob/main/.github/workflows/bug-test.md)
+agentic workflows on issues. They separate diagnosis, remediation, and
+verification with human-controlled handoffs; the fix is proposed as a draft
+PR for maintainer review. **Today these project
+workflows do not consume Spec Kit's bundled
+[`bug` extension](bugfix.md)**, even though it offers a corresponding
+assess, fix, test process for users. Having the workflows use that extension
+is a direction for future work, not a current capability or a promised
+release.
+
+Agentic and conventional workflows both run on GitHub Actions. What changes
+is whether an agent interprets evidence or proposes a change.
+[Dependabot](https://github.com/github/spec-kit/blob/main/.github/dependabot.yml)
+also proposes weekly pip and GitHub Actions dependency-update PRs for
+maintainer review; it is conventional automation, not an agentic workflow.
+
+## Extensibility and community practice
+
+Extensibility cuts across this SDLC: the project builds and distributes
+processes as well as using them. The team ships the
+[`assess` bundle](https://github.com/github/spec-kit/tree/main/bundles/assess)
+and [`bugfix` bundle](https://github.com/github/spec-kit/tree/main/bundles/bugfix),
+each combining an extension with a resumable *Spec Kit workflow* and a human
+review gate. It also ships the
+[`lean` preset](https://github.com/github/spec-kit/tree/main/presets/lean)
+to demonstrate an alternative way of shaping core SDD guidance. These are
+Spec Kit's own [extensions, presets, workflows, and bundles](customization.md),
+not the repository's GitHub Actions workflows.
+
+★ Beyond core feature delivery, agentic community-submission workflows for
+[extensions](https://github.com/github/spec-kit/blob/main/.github/workflows/add-community-extension.md),
+[presets](https://github.com/github/spec-kit/blob/main/.github/workflows/add-community-preset.md),
+and [bundles](https://github.com/github/spec-kit/blob/main/.github/workflows/add-community-bundle.md)
+validate submission metadata and propose catalog changes in draft PRs for
+maintainer review.
+
+Catalog discovery does not audit or endorse community code; users must
+review third-party components before use.
+
+## How we went from SDLC to an agentic SDLC
+
+Agentic practices were layered into an existing SDLC, not substituted for
+conventional checks and releases. The commit history shows how that mix
+emerged over time. These are selected milestones, not an exhaustive
+changelog. The same star marks agentic milestones, including use of Spec
+Kit's SDD process; conventional automation and policies are unmarked.
+
+| Month | What changed |
+| --- | --- |
+| August 2025 | <ul><li><a href="https://github.com/github/spec-kit/commit/28fdfaa8">GitHub Release automation</a> was added.</li></ul> |
+| September 2025 | <ul><li><a href="https://github.com/github/spec-kit/commit/4b98c20f">Documentation deployment</a> was added.</li><li><a href="https://github.com/github/spec-kit/commit/6f3e450c">Contribution guidelines</a> began requiring disclosure of AI assistance, including contributor-run agents.</li></ul> |
+| October 2025 | <ul><li><a href="https://github.com/github/spec-kit/commit/33a07969">Markdown linting</a> was added to PR and <code>main</code> checks.</li></ul> |
+| February 2026 | <ul><li><a href="https://github.com/github/spec-kit/pull/1622">Dependabot</a> began proposing weekly pip and GitHub Actions dependency-update PRs.</li><li>A <a href="https://github.com/github/spec-kit/commit/9402ebd0">CodeQL workflow</a> was added for code scanning.</li><li><a href="https://github.com/github/spec-kit/pull/1637">Pytest CI</a> began running tests on PRs and pushes to <code>main</code>.</li><li><a href="https://github.com/github/spec-kit/pull/1637">Ruff linting</a> was added to the Python CI workflow.</li></ul> |
+| May 2026 | <ul><li><a href="https://github.com/github/spec-kit/pull/2655">Extension submissions</a> gained catalog validation and draft PRs. &#9733;</li><li><a href="https://github.com/github/spec-kit/pull/2655">Preset submissions</a> gained catalog validation and draft PRs. &#9733;</li></ul> |
+| June 2026 | <ul><li>An <a href="https://github.com/github/spec-kit/pull/3023">agentic bug-assess workflow</a> was added. &#9733;</li><li>The <a href="https://github.com/github/spec-kit/commit/3fd1e54d4b237af6124bb967e2eae24c93685a89">bundler feature</a> used Spec Kit's SDD process to produce its specification, plan, and tasks. &#9733;</li><li><a href="https://github.com/github/spec-kit/pull/2915">PyPI publishing</a> gained a conventional workflow.</li><li><a href="https://github.com/github/spec-kit/pull/3126">ShellCheck</a> began checking shell scripts in CI.</li></ul> |
+| July 2026 | <ul><li><a href="https://github.com/github/spec-kit/pull/3258">Bug-fix</a> extended the agentic issue workflow with a human handoff. &#9733;</li><li><a href="https://github.com/github/spec-kit/pull/3257">Bug-test</a> added a separate verification stage. &#9733;</li><li><a href="https://github.com/github/spec-kit/pull/3553">Bundle submissions</a> gained catalog automation. &#9733;</li></ul> |
+| August 2026 | <ul><li>The <a href="https://github.com/github/spec-kit/pull/4186">feature-assess workflow</a> began using Spec Kit's <code>assess</code> extension on feature requests. &#9733;</li></ul> |
+| September 2026 | <ul><li><a href="https://github.com/github/spec-kit/pull/4512">AI disclosure</a> began requiring agent, model, settings, and extent.</li><li><a href="https://github.com/github/spec-kit/pull/4752">Contribution guidance</a> added attribution for agent-authored commits and comments.</li></ul> |
+
+This was not a handoff from conventional automation to agents. Tests, lint,
+scanning, and publishing kept repeatable work in GitHub Actions, while
+disclosure made contributor-run agents visible. The project added agentic
+catalog and bug workflows for bounded tasks, used SDD on a substantial
+feature, and later made feature assessment consume Spec Kit's `assess`
+extension. These were separate additions, not steps every issue must follow.
+
+Together they give the project choices. For features, `assess` can inform a
+human decision about a request; substantial implementation work can use SDD
+to specify and plan it, as the bundler did. There is no automatic handoff
+between those processes. A small change can stay in an issue and PR, while
+a bug can move through human-gated assessment, repair, and verification.
+Code changes still face conventional checks and maintainer review; issue
+verdicts and catalog proposals have their own human gates.
+
+## A production practice, not a prescribed recipe
+
+For this public open-source project, a new issue is untrusted input, not
+permission to run an agent. A maintainer activates each repository-owned
+agentic workflow with its label and decides when work advances; contributors
+can also bring their own agents, subject to disclosure and review. These are
+deliberate boundaries for this project, not inherent limits of Spec Kit.
+
+A closed project with a different trust model could automate more handoffs
+between assessment, specification, implementation, and testing, while
+keeping permissions, evidence, and review appropriate to the risk. Spec Kit's
+production mix is not a prescribed recipe: teams can adopt agents in
+different places, with or without Spec Kit's processes. That mix can change
+with the project's needs and practices.
+
+Here, agentic does not mean human-free: contributors still bring problems,
+requirements, and changes; maintainers steer product direction, guide
+delivery, and review evidence. Conventional automation handles repeatable
+checks and publishing, while agents help with bounded work that requires
+interpretation. This division aims to focus human time on judgment, though
+the timeline shows adoption rather than measured time savings.

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/guides/monorepo.md

@@ -78,8 +78,14 @@ ERROR: SPECIFY_INIT_DIR is not a Spec Kit project (no .specify/ directory): /hom
 ```
 
 `SPECIFY_INIT_DIR` selects the **project**; `SPECIFY_FEATURE_DIRECTORY` selects
-the **feature** within it. They compose: set both to pick a project and a
-feature non-interactively. See the
+the **feature**. A relative feature path is joined to that project root
+without a containment check, so a value like `../shared-feature` still
+resolves outside it; an absolute path is used as-is and may likewise point
+outside the project root. Either way, the selected feature directory is not
+required to live inside it — the project root identifies the Spec Kit project
+and its command/configuration context, not a containment boundary for feature
+documents. They compose: set both to pick a project and a feature
+non-interactively. See the
 [`SPECIFY_INIT_DIR` reference](../reference/core.md#environment-variables) for
 the full contract and the two-axes model.
 

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/index.md

@@ -27,6 +27,9 @@ These are independent entry points, not mandatory phases. SDD ships in core.
 Bug fixing and assessment are bundled, opt-in extensions. Assessment can stand
 alone; a decision to proceed does not automatically start implementation.
 
+See [how the Spec Kit project runs its agentic SDLC](guides/agentic-sdlc.md)
+and where it uses Spec Kit itself.
+
 Adding Spec Kit to an established codebase? Start with the
 [existing-project guide](guides/existing-projects.md).
 
@@ -139,6 +142,10 @@ Community extensions like CI Guard and Architecture Guard add compliance gates a
 ## Explore the docs
 
 <div class="nav-cards">
+  <a href="guides/agentic-sdlc.md" class="nav-card">
+    <strong>Spec Kit's Agentic SDLC</strong>
+    <span>How this project assesses, builds, tests, ships, and repairs changes</span>
+  </a>
   <a href="quickstart.md" class="nav-card">
     <strong>Spec-Driven Development</strong>
     <span>Define, plan, implement, and converge on a feature</span>
@@ -198,4 +205,4 @@ Ready to start? [Choose your process](#choose-your-process).
 
 </div>
 
-<p class="text-end small text-body-secondary">Last updated: September 14, 2026</p>
+<p class="text-end small text-body-secondary">Last updated: September 28, 2026</p>

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/installation.md

@@ -147,7 +147,12 @@ After initialization, you should see the following commands available in your co
 - `/speckit.checklist` - Generate quality checklists
 - `/speckit.constitution` - Create or update project principles
 - `/speckit.converge` - Assess codebase against artifacts and append remaining tasks
-- `/speckit.taskstoissues` - Convert tasks to issues
+- `/speckit.taskstoissues` - Convert tasks to issues (moving to the bundled `github` extension as
+  `/speckit.github.taskstoissues`; install it with `specify extension add github`)
+
+The `generic` integration scaffolds core commands or skills, but does not
+register extension add-ons; installing `github` there does not make its
+replacement command invokable. See the [GitHub extension's installation notes](https://github.com/github/spec-kit/blob/main/extensions/github/README.md#installation).
 
 Scripts are installed into a variant subdirectory matching the chosen script type:
 

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/reference/agentic-sdd.md

@@ -171,3 +171,6 @@ This command requires a GitHub `origin` remote and access to the GitHub MCP tool
 for listing and creating issues. It creates issues only in the repository
 identified by that remote and checks existing task IDs to avoid duplicates.
 It is not required to implement tasks or converge on a feature.
+
+> [!NOTE]
+> GitHub issue tracking is moving out of core into the bundled, opt-in [`github` extension](https://github.com/github/spec-kit/blob/main/extensions/github/README.md). `/speckit.taskstoissues` still works and is unchanged, but its replacement, `/speckit.github.taskstoissues`, is available via `specify extension add github` for integrations that register extension add-ons. The `generic` integration does not register them in either commands or skills mode; see the [installation and migration notes](https://github.com/github/spec-kit/blob/main/extensions/github/README.md#installation).

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/reference/bundles.md

@@ -174,6 +174,8 @@ from; `discovery-only` sources appear in `search` and `info` but refuse
 installation. Inspect the active stack before installing a bundle from a
 non-default source.
 
+> **Vet both the bundle source and its component catalogs.** A project can supply its own bundle catalog and `install-allowed` component catalogs (extension, preset, workflow, and step) under `.specify/`; that project configuration existing is not evidence anything in it was reviewed. Before installing a bundle from an unfamiliar project, run `specify bundle catalog list` — and the equivalent `extension`/`preset`/`workflow catalog list` and `specify workflow step catalog list` commands for the components it pulls in — and treat any source you didn't add yourself as unvetted until you've reviewed it.
+
 ### List the Catalog Stack
 
 ```bash

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/reference/core.md

@@ -52,11 +52,11 @@ 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_DIRECTORY` | Override the active feature directory (takes precedence over `.specify/feature.json`). A relative path is joined to the project root without a containment check, so a value like `../shared-feature` still resolves outside it; an absolute path is used as-is and may likewise point outside the project root. The project root still identifies the Spec Kit project and its command/configuration context, but the selected feature directory itself is not required to live under it. Combine with `SPECIFY_INIT_DIR` to pick both the project and the feature non-interactively. |
 | `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. |
 | `SPECIFY_FEATURE_NO_PERSIST` | Set to `1` or `true` to stop every core script from writing `.specify/feature.json`, even when it would otherwise persist `SPECIFY_FEATURE_DIRECTORY` on read. Useful when multiple agents run concurrently against the same checkout, each with its own `SPECIFY_FEATURE_DIRECTORY`: without it, each invocation's persist step can overwrite another agent's pinned feature 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.
+> **Two resolution axes.** `SPECIFY_INIT_DIR` selects the **project** (which directory contains `.specify/`); `SPECIFY_FEATURE_DIRECTORY` / `.specify/feature.json` select the **feature** — its default location is under `specs/` in that project, but an explicitly selected feature directory is not restricted to living inside it. They are independent — project first, then feature.
 >
 > **Version control.** `specify init` scaffolds a managed `.specify/.gitignore` that excludes machine-local state — `feature.json` (the current-feature pointer, rewritten on every feature switch) and per-machine extension `extensions/*/local-config.yml` overrides — while leaving everything else under `.specify/` (constitution, templates, scripts, extension config) shareable so teams stay aligned. Like the rest of `.specify/`'s shared scripts and templates, the file is tracked in the shared-infrastructure manifest: your edits are preserved on re-init and `specify init --here --force` restores the managed content. It is intentionally left in place by `specify integration uninstall`, which only removes the uninstalled agent's own files.
 >

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/reference/integrations.md

@@ -33,6 +33,7 @@ The Specify CLI supports a wide range of AI coding agents. When you run `specify
 | [Kimi Code](https://code.kimi.com/)                                                  | `kimi`           | Skills-based integration; installs into `.kimi-code/skills/`. `--migrate-legacy` moves old `.kimi/skills/` installs to the new paths |
 | [Kiro CLI](https://kiro.dev/docs/cli/)                                               | `kiro-cli`       | Kiro CLI does not substitute `$ARGUMENTS` in file-based prompts, so Spec Kit ships a prose fallback at render time (see [Manage prompts](https://kiro.dev/docs/cli/chat/manage-prompts/) and issue [#1926](https://github.com/github/spec-kit/issues/1926)). Alias: `--integration kiro` |
 | [Lingma](https://lingma.aliyun.com/)                                                 | `lingma`         | Skills-based integration; skills are installed automatically                                                                               |
+| [MiniMax Code](https://github.com/MiniMax-AI/minimax-code)                          | `mcode`          | Skills-based integration; installs skills into `.minimax/skills` and invokes them as `/speckit-<command>`. Headless workflow dispatch uses `--permission full` so tool actions are not blocked by headless permission gating; set `SPECKIT_INTEGRATION_MCODE_EXTRA_ARGS="--permission smart"` to use MiniMax Code's stricter policy. |
 | [Mistral Vibe](https://github.com/mistralai/mistral-vibe)                            | `vibe`           |                                                                                                                                           |
 | [Muse Code](https://dev.meta.ai/docs/muse-code)                                     | `muse`           | Skills-based integration; installs skills into `.agents/skills` and invokes them as `/speckit-<command>`                                   |
 | [Oh My Pi](https://www.npmjs.com/package/@oh-my-pi/pi-coding-agent)                  | `omp`            | Installs slash commands into `.omp/commands`                                                                                               |
@@ -317,6 +318,7 @@ The currently declared multi-install safe integrations are:
 | `kilocode` | `.kilo/commands` |
 | `kiro-cli` | `.kiro/prompts` |
 | `lingma` | `.lingma/skills` |
+| `mcode` | `.minimax/skills` |
 | `omp` | `.omp/commands` |
 | `opencode` | `.opencode/commands` |
 | `pi` | `.pi/prompts` |

{specify_cli-1.0.12 → specify_cli-1.0.13}/docs/reference/presets.md

@@ -138,6 +138,8 @@ Changes the resolution priority of an installed preset. Lower numbers take prece
 
 Preset catalogs control where `search` and `add` look for presets. Catalogs are checked in priority order (lower number = higher precedence).
 
+> **A project's `.specify/preset-catalogs.yml` can point `add` and `search` at a catalog you didn't choose.** Before installing a preset in an unfamiliar project, run `specify preset catalog list` and inspect any catalog marked install-allowed — a project supplying that config, or marking a catalog install-allowed, is not evidence its presets were reviewed. Only mark a catalog `install_allowed` for one you authored or have vetted yourself; leave unfamiliar and community catalogs discovery-only.
+
 ### List Catalogs
 
 ```bash
@@ -156,7 +158,7 @@ specify preset catalog add <url>
 | -------------------------------------------- | -------------------------------------------------- |
 | `--name <name>`                              | Required. Unique name for the catalog              |
 | `--priority <N>`                             | Priority (default: 10; lower = higher precedence)  |
-| `--install-allowed / --no-install-allowed`   | Whether presets can be installed from this catalog (default: discovery only) |
+| `--install-allowed / --no-install-allowed`   | Whether presets can be installed from this catalog (default: discovery only). Only enable for a catalog you own and vet; never enable it for an unvetted public catalog. |
 | `--description <text>`                       | Optional description                               |
 
 Adds a catalog to the project's `.specify/preset-catalogs.yml`.