specify-cli 0.10.0__tar.gz → 0.10.2__tar.gz

{specify_cli-0.10.0 → specify_cli-0.10.2}/.github/skills/add-community-extension/SKILL.md

@@ -70,6 +70,8 @@ Use the existing entries as the format template. Required fields:
     "documentation": "<documentation>",
     "changelog": "<changelog>",
     "license": "<license>",
+    "category": "<category>",
+    "effect": "<effect>",
     "requires": {
       "speckit_version": "<speckit_version>"
     },
@@ -87,6 +89,9 @@ Use the existing entries as the format template. Required fields:
 }
 ```
 
+**Category** — free-form string; common values: `docs`, `code`, `process`, `integration`, `visibility`
+**Effect** — one of: `read-only`, `read-write`
+
 If the extension has optional tool dependencies, add a `"tools"` array inside `"requires"`:
 
 ```json
@@ -113,8 +118,8 @@ Determine the category and effect from the extension's behavior:
 | <Name> | <Description> | `<category>` | <Effect> | [<repo-name>](<repository-url>) |
 ```
 
-**Category** — one of: `docs`, `code`, `process`, `integration`, `visibility`
-**Effect** — `Read-only` (produces reports only) or `Read+Write` (modifies project files)
+**Category** — free-form; common values: `docs`, `code`, `process`, `integration`, `visibility`
+**Effect** — write canonical values `read-only` or `read-write` in `extension.yml` and `catalog.community.json`; use `Read-only`/`Read+Write` only for the docs table display
 
 ### 6. Commit, push, and open PR
 

{specify_cli-0.10.0 → specify_cli-0.10.2}/CHANGELOG.md

@@ -2,6 +2,35 @@
 
 <!-- insert new changelog below this comment -->
 
+## [0.10.2] - 2026-06-11
+
+### Changed
+
+- Add Research Harness extension to community catalog (#2935)
+- Add Coding Standards Drift Control extension to community catalog (#2934)
+- Add Spec Trace extension to community catalog (#2527)
+- fix(extensions): preserve argument-hint in extension Claude SKILL.md (#2916)
+- fix(presets): harden preset URL installs against unsafe redirects (#2911)
+- fix: skip recovered files during refresh_managed overwrite check (#2918) (#2919)
+- Update multi-model-review extension to v0.1.1 (#2900)
+- feat: add category and effect as first-class fields in extension schema (#2899)
+- chore(catalog): add Jira Integration (Sync Engine) extension (#2895)
+- chore: release 0.10.1, begin 0.10.2.dev0 development (#2910)
+
+## [0.10.1] - 2026-06-09
+
+### Changed
+
+- Update DocGuard — CDD Enforcement extension to v0.25.1 (#2909)
+- Update a11y-governance preset to v0.3.0 (#2867)
+- docs: document spec persistence models (#2856)
+- chore(catalog): bump Linear Integration to v0.3.0 (repo renamed to spec-kit-linear-sync) (#2893)
+- chore: update DocGuard extension to v0.25.0 (#2707)
+- chore: remove unused open_github_url/_StripAuthOnRedirect from _github_http.py (#2883)
+- fix(catalogs): validate extension and preset catalog payload shape (#2621)
+- feat(integration): add status reporting (#2674)
+- chore: release 0.10.0, begin 0.10.1.dev0 development (#2904)
+
 ## [0.10.0] - 2026-06-09
 
 ### Changed

{specify_cli-0.10.0 → specify_cli-0.10.2}/PKG-INFO

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

@@ -7,7 +7,7 @@
 
 The following community-contributed extensions are available in [`catalog.community.json`](https://github.com/github/spec-kit/blob/main/extensions/catalog.community.json):
 
-**Categories:**
+**Categories** (common values, but any string is allowed):
 
 - `docs` — reads, validates, or generates spec artifacts
 - `code` — reviews, validates, or modifies source code
@@ -15,10 +15,13 @@ The following community-contributed extensions are available in [`catalog.commun
 - `integration` — syncs with external platforms
 - `visibility` — reports on project health or progress
 
-**Effect:**
+**Effect** (canonical `extension.yml`/catalog values):
 
-- `Read-only` — produces reports without modifying files
-- `Read+Write` — modifies files, creates artifacts, or updates specs
+- `read-only` — produces reports without modifying files (displayed as `Read-only` in the table)
+- `read-write` — modifies files, creates artifacts, or updates specs (displayed as `Read+Write` in the table)
+
+> [!TIP]
+> Extension authors can declare `category` and `effect` in their `extension.yml` under the `extension:` block. These fields are also available in `catalog.community.json` for tooling and the CLI (`specify extension info`).
 
 | Extension | Purpose | Category | Effect | URL |
 |-----------|---------|----------|--------|-----|
@@ -41,10 +44,11 @@ The following community-contributed extensions are available in [`catalog.commun
 | CI Guard | Spec compliance gates for CI/CD — verify specs exist, check drift, and block merges on gaps | `process` | Read-only | [spec-kit-ci-guard](https://github.com/Quratulain-bilal/spec-kit-ci-guard) |
 | Checkpoint Extension | Commit the changes made during the middle of the implementation, so you don't end up with just one very large commit at the end | `code` | Read+Write | [spec-kit-checkpoint](https://github.com/aaronrsun/spec-kit-checkpoint) |
 | Cleanup Extension | Post-implementation quality gate that reviews changes, fixes small issues (scout rule), creates tasks for medium issues, and generates analysis for large issues | `code` | Read+Write | [spec-kit-cleanup](https://github.com/dsrednicki/spec-kit-cleanup) |
+| Coding Standards Drift Control | Generate coding-standards drift reports and remediation tasks for active Spec Kit features | `code` | Read+Write | [spec-kit-coding-standards-drift-control](https://github.com/benizzio/spec-kit-coding-standards-drift-control) |
 | Conduct Extension | Orchestrates spec-kit phases via sub-agent delegation to reduce context pollution. | `process` | Read+Write | [spec-kit-conduct-ext](https://github.com/twbrandon7/spec-kit-conduct-ext) |
 | Confluence Extension | Create a doc in Confluence summarizing the specifications and planning files | `integration` | Read+Write | [spec-kit-confluence](https://github.com/aaronrsun/spec-kit-confluence) |
 | Cost Tracker | Track real LLM dollar cost across SDD workflows — per-feature budgets, per-integration comparison, and finance-ready exports | `visibility` | Read+Write | [spec-kit-cost](https://github.com/Quratulain-bilal/spec-kit-cost) |
-| DocGuard — CDD Enforcement | Canonical-Driven Development enforcement. Validates, scores, and traces project documentation with automated checks, AI-driven workflows, and spec-kit hooks. Zero NPM runtime dependencies. | `docs` | Read+Write | [spec-kit-docguard](https://github.com/raccioly/docguard) |
+| DocGuard — CDD Enforcement | Canonical-Driven Development enforcement. Validates, scores, and traces project documentation with automated checks, AI-driven workflows, and spec-kit hooks. One pinned runtime dependency; pure Node.js otherwise. | `docs` | Read+Write | [spec-kit-docguard](https://github.com/raccioly/docguard) |
 | Extensify | Create and validate extensions and extension catalogs | `process` | Read+Write | [extensify](https://github.com/mnriem/spec-kit-extensions/tree/main/extensify) |
 | Fix Findings | Automated analyze-fix-reanalyze loop that resolves spec findings until clean | `code` | Read+Write | [spec-kit-fix-findings](https://github.com/Quratulain-bilal/spec-kit-fix-findings) |
 | FixIt Extension | Spec-aware bug fixing — maps bugs to spec artifacts, proposes a plan, applies minimal changes | `code` | Read+Write | [spec-kit-fixit](https://github.com/speckit-community/spec-kit-fixit) |
@@ -55,8 +59,9 @@ The following community-contributed extensions are available in [`catalog.commun
 | Intelligent Agent Orchestrator | Cross-catalog agent discovery and intelligent prompt-to-command routing | `process` | Read+Write | [spec-kit-orchestrator](https://github.com/pragya247/spec-kit-orchestrator) |
 | Iterate | Iterate on spec documents with a two-phase define-and-apply workflow — refine specs mid-implementation and go straight back to building | `docs` | Read+Write | [spec-kit-iterate](https://github.com/imviancagrace/spec-kit-iterate) |
 | Jira Integration | Create Jira Epics, Stories, and Issues from spec-kit specifications and task breakdowns with configurable hierarchy and custom field support | `integration` | Read+Write | [spec-kit-jira](https://github.com/mbachorik/spec-kit-jira) |
+| Jira Integration (Sync Engine) | Idempotent, drift-aware, fail-closed reconcile engine mirroring spec-kit specs into Jira (Epic per repo, Story per spec, Subtask per phase) | `integration` | Read+Write | [spec-kit-jira-sync](https://github.com/ashbrener/spec-kit-jira-sync) |
 | Learning Extension | Generate educational guides from implementations and enhance clarifications with mentoring context | `docs` | Read+Write | [spec-kit-learn](https://github.com/imviancagrace/spec-kit-learn) |
-| Linear Integration | Mirror spec-kit feature directories into Linear (filesystem → Linear, reconcile-based, unidirectional). | `integration` | Read+Write | [spec-kit-linear](https://github.com/ashbrener/spec-kit-linear) |
+| Linear Integration | Mirror spec-kit feature directories into Linear (filesystem → Linear, reconcile-based, unidirectional). | `integration` | Read+Write | [spec-kit-linear-sync](https://github.com/ashbrener/spec-kit-linear-sync) |
 | MAQA — Multi-Agent & Quality Assurance | Coordinator → feature → QA agent workflow with parallel worktree-based implementation. Language-agnostic. Auto-detects installed board plugins. Optional CI gate. | `process` | Read+Write | [spec-kit-maqa-ext](https://github.com/GenieRobot/spec-kit-maqa-ext) |
 | MAQA Azure DevOps Integration | Azure DevOps Boards integration for MAQA — syncs User Stories and Task children as features progress | `integration` | Read+Write | [spec-kit-maqa-azure-devops](https://github.com/GenieRobot/spec-kit-maqa-azure-devops) |
 | MAQA CI/CD Gate | Auto-detects GitHub Actions, CircleCI, GitLab CI, and Bitbucket Pipelines. Blocks QA handoff until pipeline is green. | `process` | Read+Write | [spec-kit-maqa-ci](https://github.com/GenieRobot/spec-kit-maqa-ci) |
@@ -88,6 +93,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Ralph Loop | Autonomous implementation loop using AI agent CLI | `code` | Read+Write | [spec-kit-ralph](https://github.com/Rubiss-Projects/spec-kit-ralph) |
 | Reconcile Extension | Reconcile implementation drift by surgically updating feature artifacts. | `docs` | Read+Write | [spec-kit-reconcile](https://github.com/stn1slv/spec-kit-reconcile) |
 | Red Team | Adversarial review of specs before /speckit.plan — parallel lens agents surface risks that clarify/analyze structurally can't (prompt injection, integrity gaps, cross-spec drift, silent failures). Produces a structured findings report; no auto-edits to specs. | `docs` | Read+Write | [spec-kit-red-team](https://github.com/ashbrener/spec-kit-red-team) |
+| Research Harness | State-externalizing research harness: budgeted exploration, evidence curation, and claim verification for spec-driven development | `process` | Read+Write | [spec-kit-harness](https://github.com/formin/spec-kit-harness) |
 | Repository Index | Generate index for existing repo for overview, architecture and module level. | `docs` | Read-only | [spec-kit-repoindex](https://github.com/liuyiyu/spec-kit-repoindex) |
 | Reqnroll BDD | Adds Reqnroll BDD planning, Gherkin generation, traceability, safe task injection, handoff, and verification to Spec Kit | `process` | Read+Write | [spec-kit-reqnroll-bdd](https://github.com/LoogacyStudio/spec-kit-reqnroll-bdd) |
 | Retro Extension | Sprint retrospective analysis with metrics, spec accuracy assessment, and improvement suggestions | `process` | Read+Write | [spec-kit-retro](https://github.com/arunt14/spec-kit-retro) |
@@ -107,6 +113,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Spec Refine | Update specs in-place, propagate changes to plan and tasks, and diff impact across artifacts | `process` | Read+Write | [spec-kit-refine](https://github.com/Quratulain-bilal/spec-kit-refine) |
 | Spec Scope | Effort estimation and scope tracking — estimate work, detect creep, and budget time per phase | `process` | Read-only | [spec-kit-scope-](https://github.com/Quratulain-bilal/spec-kit-scope-) |
 | Spec Sync | Detect and resolve drift between specs and implementation. AI-assisted resolution with human approval | `docs` | Read+Write | [spec-kit-sync](https://github.com/bgervin/spec-kit-sync) |
+| 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) |
 | SpecTest | Auto-generate test scaffolds from spec criteria, map coverage, and find untested requirements | `code` | Read+Write | [spec-kit-spectest](https://github.com/Quratulain-bilal/spec-kit-spectest) |

{specify_cli-0.10.0 → specify_cli-0.10.2}/docs/community/presets.md

@@ -7,7 +7,7 @@ The following community-contributed presets customize how Spec Kit behaves — o
 
 | Preset | Purpose | Provides | Requires | URL |
 |--------|---------|----------|----------|-----|
-| A11Y Governance | Adds WCAG 2.2 AA accessibility checks, bilingual DE/EN delivery, CEFR-B2 readability, CLI accessibility, and inclusive-content guidance | 9 templates, 3 commands | — | [spec-kit-preset-a11y-governance](https://github.com/hindermath/spec-kit-preset-a11y-governance) |
+| A11Y Governance | Adds WCAG 2.2 AA accessibility checks, bilingual DE/EN delivery, CEFR-B2 readability, CLI accessibility, inclusive-content guidance, and didactic inline-code-comment review | 10 templates, 3 commands | — | [spec-kit-preset-a11y-governance](https://github.com/hindermath/spec-kit-preset-a11y-governance) |
 | Agent Parity Governance | Keeps shared AI-agent instructions aligned and adds agent-neutral Spec Kit model-routing guidance across project-defined agent guidance surfaces | 9 templates, 3 commands | — | [spec-kit-preset-agent-parity-governance](https://github.com/hindermath/spec-kit-preset-agent-parity-governance) |
 | AIDE In-Place Migration | Adapts the AIDE extension workflow for in-place technology migrations (X → Y pattern) — adds migration objectives, verification gates, knowledge documents, and behavioral equivalence criteria | 2 templates, 8 commands | AIDE extension | [spec-kit-presets](https://github.com/mnriem/spec-kit-presets) |
 | Architecture Governance | Adds secure architecture governance: trust boundaries, threat modeling, STRIDE/CAPEC, S-ADRs, Zero Trust applicability, and OWASP SAMM | 11 templates, 3 commands | — | [spec-kit-preset-architecture-governance](https://github.com/hindermath/spec-kit-preset-architecture-governance) |

{specify_cli-0.10.0 → specify_cli-0.10.2}/docs/concepts/sdd.md

@@ -11,6 +11,11 @@ Spec-Driven Development is a structured process that emphasizes:
 - **Multi-step refinement** rather than one-shot code generation from prompts
 - **Heavy reliance** on advanced AI model capabilities for specification interpretation
 
+Spec Kit does not prescribe how teams preserve or mutate `spec.md`, `plan.md`,
+and `tasks.md` after requirements change. See
+[Spec Persistence Models](spec-persistence.md) for three common ways to manage
+those artifacts over time.
+
 ## Development Phases
 
 | Phase | Focus | Key Activities |

specify_cli-0.10.2/docs/concepts/spec-persistence.md

@@ -0,0 +1,107 @@
+# Spec Persistence Models
+
+Spec Kit intentionally leaves teams in control of what happens to `spec.md`,
+`plan.md`, and `tasks.md` after requirements change. The toolkit gives you a
+repeatable workflow, but it does not force one artifact maintenance strategy.
+
+This page names three common models so teams can make that choice explicit.
+None is the default, and none is required by Spec Kit.
+
+## Two Separate Questions
+
+Spec-driven development has a temporal question: how long should the
+specification matter? One
+[overview of SDD tooling](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
+frames that lifecycle in three levels:
+
+- **Spec-first**: write a spec before coding, then allow it to be discarded.
+- **Spec-anchored**: keep the spec after implementation and use it for future
+  changes.
+- **Spec-as-source**: treat the spec as the only human-edited source and
+  regenerate implementation artifacts from it.
+
+Spec Kit also exposes a second question: what happens to the artifact set when
+requirements change? The models below describe that mutation strategy.
+
+## Flow-Back Spec
+
+Use flow-back when `spec.md`, `plan.md`, `tasks.md`, and the implementation are
+all allowed to inform each other.
+
+In this model, edits can begin in any artifact. A developer might update
+`tasks.md` during implementation, revise `plan.md` after a technical discovery,
+or adjust `spec.md` after a product clarification. The team then reconciles the
+artifact set manually so the final project history still makes sense.
+
+Flow-back works well when:
+
+- the team is small enough to notice and reconcile drift quickly
+- implementation discoveries are expected to reshape the original plan
+- speed matters more than preserving each intermediate decision as immutable
+  history
+
+The main risk is silent divergence. If the team changes lower-level artifacts
+without reflecting the decision back into `spec.md`, future contributors may
+not know which artifact to trust.
+
+## Flow-Forward Spec
+
+Use flow-forward when each feature directory should remain a historical record.
+
+In this model, completed artifacts are treated as immutable. When requirements
+change, the team creates a new feature directory instead of mutating the
+existing `spec.md`, `plan.md`, or `tasks.md`. The older directory remains useful
+for audit, comparison, or explaining how the project reached its current state.
+
+Flow-forward works well when:
+
+- auditability and traceability matter
+- features are well-scoped and rarely revisited in place
+- the team wants a clear sequence of requirement changes over time
+
+The main tradeoff is duplication. Related decisions can be spread across
+multiple feature directories, so teams need naming, linking, or review habits
+that make the lineage easy to follow.
+
+## Living Spec
+
+Use living spec when `spec.md` is the contract and the other artifacts are
+derived from it.
+
+In this model, teams update `spec.md` first and then regenerate or revise
+`plan.md` and `tasks.md` from that source. The plan and task list are still
+valuable, but they are treated as disposable derivations rather than permanent
+sources of truth.
+
+Living spec works well when:
+
+- the product contract is stable enough to own the workflow
+- the team is comfortable regenerating derived artifacts after spec changes
+- consistency between requirements and implementation matters more than keeping
+  every intermediate plan intact
+
+The main risk is losing useful implementation rationale if derived artifacts are
+discarded without preserving important decisions elsewhere.
+
+## Choosing a Model
+
+The model is a team convention, not a CLI setting. A project can even use
+different models in different areas, as long as contributors know which one
+applies.
+
+| Model | Mutation rule | Best fit | Watch out for |
+|---|---|---|---|
+| Flow-back spec | Edit any artifact, then reconcile | Fast iteration and close collaboration | Silent drift between artifacts |
+| Flow-forward spec | Create a new feature directory for new requirements | Audit trails and historical clarity | Duplicate or fragmented context |
+| Living spec | Edit `spec.md`; regenerate derived artifacts | Spec as contract | Lost rationale in regenerated files |
+
+If your team has not chosen a model yet, start by answering two questions:
+
+1. Should completed feature directories be historical records or editable work
+   areas?
+2. Is `spec.md` the single source of truth, or are `plan.md` and `tasks.md`
+   allowed to become co-equal sources?
+
+Once those answers are clear, document the convention in your project
+constitution or team onboarding notes so future contributors know how to handle
+changes.

{specify_cli-0.10.0 → specify_cli-0.10.2}/docs/reference/integrations.md

@@ -126,6 +126,27 @@ specify integration upgrade [<key>]
 
 Reinstalls an installed integration with updated templates and commands (e.g., after upgrading Spec Kit). Defaults to the default integration; if a key is provided, it must be one of the installed integrations. Detects locally modified files and blocks the upgrade unless `--force` is used. Stale files from the previous install that are no longer needed are removed automatically. Shared templates stay aligned with the default integration even when upgrading a non-default integration.
 
+## Report Integration Status
+
+```bash
+specify integration status
+specify integration status --json
+```
+
+Reports the current project's integration status without changing files. The
+status report includes the default integration, installed integrations,
+multi-install safety, missing managed files, modified managed files, invalid
+manifest paths, shared Spec Kit infrastructure health, unchecked manifests, and
+the target integration for default-sensitive shared templates. The JSON form is
+intended for CI and coding agents that need stable machine-readable status data;
+it also reports the raw recorded integrations and the integration manifests that
+were checked when state repair heuristics differ from the recorded file.
+The command exits 0 when the report status is `ok` or `warning`; it exits 1
+only when the report status is `error`. In JSON output, `multi_install_safe`
+is `null` when no installed integration set can be evaluated, such as when the
+integration state is missing, unreadable, lacks a valid recorded integration
+list, or records no installed integrations.
+
 ## Integration-Specific Options
 
 Some integrations accept additional options via `--integration-options`:

{specify_cli-0.10.0 → specify_cli-0.10.2}/docs/toc.yml

@@ -41,6 +41,8 @@
   items:
     - name: What is SDD?
       href: concepts/sdd.md
+    - name: Spec Persistence Models
+      href: concepts/spec-persistence.md
 
 # Development workflows
 - name: Development