specify-cli 1.2.4__tar.gz → 1.2.6__tar.gz

{specify_cli-1.2.4 → specify_cli-1.2.6}/.github/ISSUE_TEMPLATE/config.yml

@@ -7,7 +7,7 @@ contact_links:
     url: https://github.com/github/spec-kit/blob/main/README.md
     about: Read the Spec Kit documentation and guides
   - name: 🛠️ Extension Development Guide
-    url: https://github.com/github/spec-kit/blob/main/extensions/EXTENSION-DEVELOPMENT-GUIDE.md
+    url: https://github.github.io/spec-kit/extensions/developing.html
     about: Learn how to develop and publish Spec Kit extensions
   - name: 🤝 Contributing Guide
     url: https://github.com/github/spec-kit/blob/main/CONTRIBUTING.md

{specify_cli-1.2.4 → specify_cli-1.2.6}/.github/ISSUE_TEMPLATE/extension_submission.yml

@@ -9,7 +9,7 @@ body:
         Thanks for contributing an extension! This template helps you submit your extension to the community catalog.
 
         **Before submitting:**
-        - Review the [Extension Publishing Guide](https://github.com/github/spec-kit/blob/main/extensions/EXTENSION-PUBLISHING-GUIDE.md)
+        - Review the [Extension Publishing Guide](https://github.github.com/spec-kit/extensions/publishing.html)
         - Ensure your extension has a valid `extension.yml` manifest
         - Create a GitHub release with a version tag (e.g., v1.0.0)
         - Test installation: `specify extension add <extension-name> --from <your-release-url>`

{specify_cli-1.2.4 → specify_cli-1.2.6}/.github/skills/add-community-extension/SKILL.md

@@ -27,7 +27,7 @@ Read the GitHub issue to extract all metadata:
 
 ### 2. Validate against publishing rules
 
-Check **all** of the following (per `extensions/EXTENSION-PUBLISHING-GUIDE.md`):
+Check **all** of the following (per `docs/extensions/publishing.md`):
 
 | Check | How |
 |-------|-----|

{specify_cli-1.2.4 → specify_cli-1.2.6}/.github/workflows/codeql.yml

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

{specify_cli-1.2.4 → specify_cli-1.2.6}/.github/workflows/lint.yml

@@ -88,7 +88,7 @@ jobs:
           fi
 
       - name: Run markdownlint-cli2
-        uses: DavidAnson/markdownlint-cli2-action@21c1be1b93ad9ed58fa840aacc3f279cde2a72ff # v24.2.0
+        uses: DavidAnson/markdownlint-cli2-action@696eb3f2509270d7b882d2aa68347bc676e7af34 # v25.0.0
         with:
           globs: ${{ env.DOC_GLOBS }}
 

{specify_cli-1.2.4 → specify_cli-1.2.6}/CHANGELOG.md

@@ -2,6 +2,56 @@
 
 <!-- insert new changelog below this comment -->
 
+## [1.2.6] - 2026-11-02
+
+### Changed
+
+- feat(droid): add --no-model-invocation integration option (#5116)
+- fix(extensions): make extension add name optional with --from (#5197)
+- fix(extensions): skip non-UTF-8 catalog responses (#5196)
+- feat: add `specify workflow definition` for run-scoped definitions (#4912)
+- fix(integrations): refresh manifest hashes after init --force and switch rollback (#5193)
+- fix(workflows): stop dispatching "None" as command step arguments (#5016)
+- feat(workflows): add opt-in strict shell execution (#5181)
+- chore(deps): bump DavidAnson/markdownlint-cli2-action (#5191)
+- chore(deps): bump the codeql-action group with 2 updates (#5189)
+- fix: reject symlinked integration state (#5176)
+- fix: reject trailing newlines in extension IDs (#5186)
+- fix: reject trailing newlines in preset IDs (#5188)
+- fix(templates): start spec.md from the composed spec-template (#5187)
+- docs: move extension API reference into documentation (#5174)
+- Update iSAQB Architecture Governance preset to v0.2.5 (#5183)
+- fix: reject unsafe self-upgrade installer paths (#5172)
+- fix(bundles): refuse to build when bundle.yml or README.md is a symlink (#5169)
+- docs(assess): clarify README invocation guidance (#5068)
+- fix(integrations): refresh manifest hashes after preset registration on switch and use (#5145)
+- chore: release 1.2.5, begin 1.2.6.dev0 development (#5167)
+
+## [1.2.5] - 2026-10-28
+
+### Changed
+
+- docs: publish extension development guide on docs site (#5166)
+- docs: publish extensions overview and navigation (#5165)
+- fix(extensions): load top-level defaults from extension.yml (#5164)
+- fix(bundles): reject integration mappings without an id (#5161)
+- docs: publish extension publishing guide on the docs site (#5163)
+- feat(workflows): expose installed workflow listing through MCP (#5115)
+- fix(extensions): reject hook commands that are not strings (#5146)
+- fix(workflows): accept equivalent version spellings in archive updates (#5155)
+- Add Domain Spec Maintenance extension to community catalog (#5162)
+- Update Architecture Governance preset to v0.6.5 (#5153)
+- Update Quality Gates (Enforcement Layer) extension to v0.5.0 (#5151)
+- Update SFSpeckit — Salesforce Spec-Driven Development to v2.0.1 (#5154)
+- docs(workflows): correct filtered-count comparison guidance (#5148)
+- fix: validate collected extension events (#5133)
+- test(workflows): pin untested workflow expression behavior (#5130)
+- fix(presets): treat non-mapping command frontmatter as empty (#5125)
+- fix(workflows): handle undecodable shell output as a step failure (#5064)
+- fix(vibe): keep user comments that follow a managed hook block (#5109)
+- [extension] Add Shared Knowledge extension to community catalog (#5140)
+- chore: release 1.2.4, begin 1.2.5.dev0 development (#5142)
+
 ## [1.2.4] - 2026-10-27
 
 ### Changed

{specify_cli-1.2.4 → specify_cli-1.2.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.2.4
+Version: 1.2.6
 Summary: Specify CLI, part of GitHub Spec Kit. A tool to bootstrap your projects for Spec-Driven Development (SDD).
 License-File: LICENSE
 Requires-Python: >=3.11

{specify_cli-1.2.4 → specify_cli-1.2.6}/bundles/assess/bundle.yml

@@ -17,7 +17,7 @@ requires:
 provides:
   extensions:
     - id: "assess"
-      version: "1.0.1"
+      version: "1.0.2"
   workflows:
     - id: "assess"
       version: "1.0.0"

{specify_cli-1.2.4 → specify_cli-1.2.6}/bundles/bugfix/bundle.yml

@@ -3,7 +3,7 @@ schema_version: "1.0"
 bundle:
   id: "bugfix"
   name: "Guided Bug Fix"
-  version: "1.0.1"
+  version: "1.0.2"
   role: "developer"
   description: "Orchestrated bug triage: assess a bug report, review the assessment behind a human gate, apply the fix, and verify it with tests."
   author: "GitHub"
@@ -17,7 +17,7 @@ requires:
 provides:
   extensions:
     - id: "bug"
-      version: "1.0.1"
+      version: "1.0.2"
   workflows:
     - id: "bugfix"
       version: "1.0.0"

{specify_cli-1.2.4 → specify_cli-1.2.6}/bundles/catalog.json

@@ -6,7 +6,7 @@
     "bugfix": {
       "id": "bugfix",
       "name": "Guided Bug Fix",
-      "version": "1.0.1",
+      "version": "1.0.2",
       "role": "developer",
       "description": "Orchestrated bug triage: assess a bug report, review behind a human gate, apply the fix, and verify with tests.",
       "author": "GitHub",

{specify_cli-1.2.4 → specify_cli-1.2.6}/design/extension.md

@@ -141,7 +141,8 @@ Catalog configuration resolves in this order:
 
 Extension configuration merges, from lowest to highest precedence:
 
-1. `config.defaults` in `extension.yml`;
+1. the top-level `defaults` and `config.defaults` in `extension.yml`, merged
+   with `config.defaults` winning on conflicting keys;
 2. `.specify/extensions/<id>/<id>-config.yml`;
 3. `.specify/extensions/<id>/local-config.yml`; and
 4. `SPECKIT_<NORMALIZED_EXTENSION_ID>_*` environment variables.

{specify_cli-1.2.4 → specify_cli-1.2.6}/design/file-helper.md

@@ -69,6 +69,16 @@ adapters. Commands using another established root call `project_files` on
 their actually selected root. Retain a helper only for the current operation;
 a later invocation resolves a new helper, so manual edits take effect.
 
+The `specify_cli.integration_state` helpers are an explicit managed-metadata
+exception to this handoff. Their reads and writes of `.specify/integration.json`
+always use deny mode, including contained links when `allow_symlinks` is true.
+This preserves the
+[integration lifecycle's restriction](integration.md#storage-loading-and-lifecycle)
+against symlinked write destinations before snapshotting and mutation.
+This guarantee does not cover unmigrated consumers such as
+`bundles.project.active_integration`, whose containment-checked reads can still
+follow contained state-file links.
+
 Existing Path-returning resolvers preflight policy without changing their return
 type or domain constructors. They do not implicitly equip unmigrated domain
 consumers with an operation helper. Failures are translated into existing

{specify_cli-1.2.4 → specify_cli-1.2.6}/design/workflow-step.md

@@ -43,6 +43,18 @@ 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.
 
+The built-in shell step preserves raw `run` interpolation by default.
+Per-step `strict: true` rejects expression markers in `run` during validation
+and execution. Its optional `env` mapping evaluates string templates separately,
+requires NUL-free string results encodable for the process environment on
+POSIX, and overrides only the child environment.
+`SPECKIT_WORKFLOW_DIR` remains engine-owned. This prevents workflow expression
+values from becoming shell source in strict mode; it is not a sandbox or a
+guarantee that an authored script handles environment data safely.
+Environment bindings and inherited settings can intentionally affect executable
+lookup, module loading, and runtime startup. Strict mode does not filter them;
+workflow source review must cover both `run` and `env` and referenced code.
+
 New runs persist an execution tree. Resume replays completed occurrences into
 their expression contexts without calling their implementations, then continues
 at the unfinished occurrence. Selected branches, custom expansions, loop

{specify_cli-1.2.4 → specify_cli-1.2.6}/docs/README.md

@@ -33,6 +33,8 @@ To build the documentation locally:
 - `guides/assessment.md` - Idea assessment walkthrough
 - `guides/customization.md` - Choosing and combining customization building blocks
 - `reference/catalogs.md` - Catalog discovery, trust, private sources, and precedence
+- `extensions/overview.md` - Extension user guide
+- `extensions/publishing.md` - Extension publishing and catalog submission guide
 - `integrations/index.md` - Integration directory and shared setup guidance
 - `integrations/cli.md` - Shared integration management CLI reference
 - `integrations/<key>.md` - Agent-specific setup, invocation, options, and limitations

{specify_cli-1.2.4 → specify_cli-1.2.6}/docs/community/extensions.md

@@ -70,6 +70,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | CSDD — Controlled Spec-Driven Development | 把治理规范、门禁、模板安装到已有仓库；第三方扩展按清单可选安装，默认不装。 | `process` | Read+Write | [csdd](https://github.com/yuansanche/csdd) |
 | Data Model Diagram | Generates Mermaid ER diagrams from Spec Kit data models after planning | `docs` | Read+Write | [spec-kit-data-model-diagram](https://github.com/benizzio/spec-kit-data-model-diagram) |
 | DocGuard — CDD Enforcement | Documentation integrity for AI-assisted repositories: lifecycle registry, drift validation, traceability, safe archival, SARIF/JUnit, MCP, GitHub Actions, and Spec Kit hooks. | `docs` | Read+Write | [spec-kit-docguard](https://github.com/raccioly/docguard) |
+| Domain Spec Maintenance | Keeps canonical per-domain specs: read before specify/plan, updated after implement | `docs` | Read+Write | [spec-kit-domain-spec](https://github.com/jinaparkdev/spec-kit-domain-spec) |
 | Dotdog | Import GitHub Spec Kit artifacts into local knowledge graphs for validation, analysis, search, and MCP queries. | `docs` | Read+Write | [dotdog](https://github.com/specdog/dotdog) |
 | DUBSAR Memory | Local project memory for Spec Kit with explicit checkpoints, cross-session resume, and SHA-256 freshness for recorded specification, plan, and task references. | `visibility` | Read+Write | [dubsar-memory](https://github.com/kotnisofiane-bit/dubsar-memory) |
 | EARS Requirements Syntax | Author, lint, and convert requirements using EARS - the five industry-standard sentence patterns for unambiguous, testable requirements | `docs` | Read+Write | [spec-kit-ears](https://github.com/dhruv-15-03/spec-kit-ears) |
@@ -137,7 +138,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Project Health Check | Diagnose a Spec Kit project and report health issues across structure, agents, features, scripts, extensions, and git | `visibility` | Read-only | [spec-kit-doctor](https://github.com/KhawarHabibKhan/spec-kit-doctor) |
 | Project Status | Show current SDD workflow progress — active feature, artifact status, task completion, workflow phase, and extensions summary | `visibility` | Read-only | [spec-kit-status](https://github.com/KhawarHabibKhan/spec-kit-status) |
 | QA Testing Extension | Systematic QA testing with browser-driven or CLI-based validation of acceptance criteria from spec | `code` | Read-only | [spec-kit-qa](https://github.com/arunt14/spec-kit-qa) |
-| Quality Gates (Enforcement Layer) | Deterministic quality enforcement for Spec Kit projects at three boundaries: the agent boundary (Claude Code PreToolUse/PostToolUse/Stop hooks), the git boundary (pre-commit / pre-merge-commit / commit-msg), and the CI boundary (projected GitHub Actions / GitLab CI / Jenkins pipelines). One policy file, one verify entrypoint, identical results at every boundary. | `process` | Read+Write | [spec-gates](https://github.com/schwichtgit/spec-gates) |
+| Quality Gates (Enforcement Layer) | Deterministic quality enforcement for Spec Kit projects at three boundaries: the agent boundary (Claude Code PreToolUse/PostToolUse/Stop hooks), the git boundary (pre-commit / pre-merge-commit / commit-msg), and the CI boundary (projected GitHub Actions / GitLab CI / Jenkins pipelines). One policy file, one verify entrypoint; CI runs the whole policy, and an earlier boundary skips only what the policy declares, by name. | `process` | Read+Write | [spec-gates](https://github.com/schwichtgit/spec-gates) |
 | RAG Azure Builder | Spec Kit extension for onboarding and operating an Azure RAG stack with guided workflows. | `process` | Read+Write | [spec-kit-extension-rag-azure-builder](https://github.com/Sertxito/spec-kit-extension-rag-azure-builder) |
 | 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 the feature's own spec, plan, and tasks. | `docs` | Read+Write | [spec-kit-reconcile](https://github.com/stn1slv/spec-kit-reconcile) |
@@ -152,7 +153,8 @@ The following community-contributed extensions are available in [`catalog.commun
 | Ripple | Detect side effects that tests can't catch after implementation — surface hidden ripple effects across 9 analysis categories | `code` | Read+Write | [spec-kit-ripple](https://github.com/chordpli/spec-kit-ripple) |
 | SDD Utilities | Resume interrupted workflows, validate project health, and verify spec-to-task traceability | `process` | Read+Write | [speckit-utils](https://github.com/mvanhorn/speckit-utils) |
 | Security Review | Full-project secure-by-design security audits plus staged, branch/PR, plan, task, follow-up, and apply reviews | `code` | Read+Write | [security-review](https://github.com/DyanGalih/security-review) |
-| SFSpeckit | Enterprise Salesforce SDLC with 18 commands for the full SDD lifecycle. | `process` | Read+Write | [spec-kit-sf](https://github.com/ysumanth06/spec-kit-sf) |
+| SFSpeckit | Enterprise-Grade Spec-Driven Development (SDD) Framework for Salesforce. | `process` | Read+Write | [spec-kit-sf](https://github.com/Evernorth/spec-kit-sf) |
+| Shared Knowledge | Inject cross-repo decisions, contracts, and conventions into your spec-kit workflow. | `integration` | Read+Write | [spec-kit-shared-knowledge](https://github.com/rnoap/spec-kit-shared-knowledge) |
 | Ship Release Extension | Automates release pipeline: pre-flight checks, branch sync, changelog generation, CI verification, and PR creation | `process` | Read+Write | [spec-kit-ship](https://github.com/arunt14/spec-kit-ship) |
 | Spec Changelog | Auto-generate changelogs and release notes from spec git history and requirement diffs | `docs` | Read-only | [spec-kit-changelog](https://github.com/Quratulain-bilal/spec-kit-changelog) |
 | Spec Critique Extension | Dual-lens critical review of spec and plan from product strategy and engineering risk perspectives | `docs` | Read-only | [spec-kit-critique](https://github.com/arunt14/spec-kit-critique) |
@@ -209,4 +211,4 @@ The following community-contributed extensions are available in [`catalog.commun
 | Worktree Isolation | Spawn isolated git worktrees for parallel feature development without checkout switching | `process` | Read+Write | [spec-kit-worktree](https://github.com/Quratulain-bilal/spec-kit-worktree) |
 | Worktrees | Default-on worktree isolation for parallel agents — sibling or nested layout | `process` | Read+Write | [spec-kit-worktree-parallel](https://github.com/dango85/spec-kit-worktree-parallel) |
 
-To submit your own extension, see the [Extension Publishing Guide](https://github.com/github/spec-kit/blob/main/extensions/EXTENSION-PUBLISHING-GUIDE.md).
+To submit your own extension, see the [Extension Publishing Guide](../extensions/publishing.md).

{specify_cli-1.2.4 → specify_cli-1.2.6}/docs/community/overview.md

@@ -50,7 +50,7 @@ Community projects that extend, visualize, or build on Spec Kit — including VS
 ## Contribute a component
 
 To publish your own work, follow the
-[Extension Publishing Guide](https://github.com/github/spec-kit/blob/main/extensions/EXTENSION-PUBLISHING-GUIDE.md),
+[Extension Publishing Guide](../extensions/publishing.md),
 the [Presets Publishing Guide](https://github.com/github/spec-kit/blob/main/presets/PUBLISHING.md),
 the [Community Bundles guide](bundles.md), or the
 [Community Workflow Step Types guide](workflow-steps.md). For help choosing a

{specify_cli-1.2.4 → specify_cli-1.2.6}/docs/community/presets.md

@@ -26,7 +26,7 @@ The following community-contributed presets customize how Spec Kit behaves — o
 | Intake Review Governance | Reviews single, series, campaign, and language-aware requirements collections before Spec Kit execution. | 9 templates, 3 commands, 5 scripts | — | [spec-kit-preset-intake-review-governance](https://github.com/hindermath/spec-kit-preset-intake-review-governance) |
 | Intake Sequencing Governance | Manages language-aware intake-series order, typed dependencies, lifecycle, and authority-neutral next-candidate selection. | 12 templates, 6 commands, 8 scripts | — | [spec-kit-preset-intake-sequencing-governance](https://github.com/hindermath/spec-kit-preset-intake-sequencing-governance) |
 | Inventory Alignment | Classifies each requirement against a read-only inventory of live IDs before writing, so reworded requirements are updated instead of duplicated. | 1 template, 2 commands | speckit-inventory extension | [spec-kit-inventory-alignment](https://github.com/Yash-Chindam/spec-kit-inventory-alignment) |
-| iSAQB Architecture Governance | Adds iSAQB/CPSA-F and arc42 architecture governance, architecture views, quality scenarios, ADRs, risks, technical-debt evidence, and provider-neutral model routing. | 14 templates, 3 commands | — | [spec-kit-preset-isaqb-architecture-governance](https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance) |
+| iSAQB Architecture Governance | Adds iSAQB/CPSA-F and arc42 architecture governance with Spec-Kit evidence for goals, views, quality scenarios, ADRs, risks, and technical debt. | 14 templates, 3 commands | — | [spec-kit-preset-isaqb-architecture-governance](https://github.com/hindermath/spec-kit-preset-isaqb-architecture-governance) |
 | Jira Issue Tracking | Overrides `speckit.taskstoissues` to create Jira epics, stories, and tasks instead of GitHub Issues via Atlassian MCP tools | 1 command | — | [spec-kit-preset-jira](https://github.com/luno/spec-kit-preset-jira) |
 | Model Driven Engineering | Focuses on streamlined commands, app repository support, cross-spec support, and capability-aware project memory for model-driven engineering workflows | 6 templates, 11 commands | MDE extension | [spec-kit-preset-mde](https://github.com/AI-MDE/spec-kit-preset-mde) |
 | Model Routing Governance | Maps provider-neutral Spec Kit roles to validated harness-local runner profiles without storing model availability, credentials, or machine-specific selections in Git. | 4 templates, 2 commands, 2 scripts | — | [spec-kit-preset-model-routing-governance](https://github.com/hindermath/spec-kit-preset-model-routing-governance) |

{specify_cli-1.2.4 → specify_cli-1.2.6}/docs/docfx.json

@@ -7,6 +7,7 @@
           "toc.yml",
           "community/*.md",
           "concepts/*.md",
+          "extensions/*.md",
           "guides/*.md",
           "integrations/*.md",
           "reference/*.md",

specify_cli-1.2.4/extensions/EXTENSION-API-REFERENCE.md → specify_cli-1.2.6/docs/extensions/api.md

@@ -44,7 +44,6 @@ provides:
     - name: string       # Required, pattern: ^speckit\.[a-z0-9-]+\.[a-z0-9-]+$
       file: string       # Required, relative path to command file
       description: string # Required
-      aliases: [string]  # Optional, same pattern as name; namespace must match extension.id and must not shadow core or installed extension commands
 
   templates:             # Optional, array of declared templates. Always resolve
                           # as "replace" -- 'strategy' is not an authorable field here.

specify_cli-1.2.4/extensions/EXTENSION-DEVELOPMENT-GUIDE.md → specify_cli-1.2.6/docs/extensions/developing.md

@@ -1,6 +1,10 @@
-# Extension Development Guide
+# Developing extensions
 
-A guide for creating Spec Kit extensions.
+A guide for creating Spec Kit extensions using GitHub Copilot's skills layout.
+Invoke skills in Copilot chat with hyphenated names such as
+`/speckit-my-ext-hello`. Extension manifests still use dotted command identifiers
+such as `speckit.my-ext.hello`; Spec Kit renders them as Copilot skills during
+installation.
 
 ---
 
@@ -41,7 +45,6 @@ provides:
     - name: "speckit.my-ext.hello"      # Must follow pattern: speckit.{ext-id}.{cmd}
       file: "commands/hello.md"
       description: "Say hello"
-      aliases: ["speckit.my-ext.hi"]    # Optional aliases, same pattern
 
   config:                               # Optional: Config files
     - name: "my-ext-config.yml"
@@ -70,7 +73,7 @@ mkdir commands
 
 **File**: `commands/hello.md`
 
-```markdown
+````markdown
 ---
 description: "Say hello command"
 tools:                              # Optional: AI tools this command uses
@@ -101,14 +104,22 @@ echo "Arguments: $ARGUMENTS"
 ## Extension Configuration
 
 Load extension config from `.specify/extensions/my-ext/my-ext-config.yml`.
+````
 
 ### 5. Test Locally
 
 ```bash
 cd /path/to/spec-kit-project
+specify integration install copilot --integration-options="--skills"
 specify extension add --dev /path/to/my-extension
 ```
 
+For a new project, initialize it with
+`specify init my-project --integration copilot --integration-options="--skills"`.
+If Copilot is already installed in a commands layout, follow the
+[Copilot migration guidance](../integrations/copilot.md#commands-layout)
+instead of installing it again.
+
 ### 6. Verify Installation
 
 ```bash
@@ -120,16 +131,17 @@ specify extension list
 #     Commands: 1 | Hooks: 1 | Status: Enabled
 ```
 
-### 7. Test Command
+### 7. Test Skill
 
-If using Claude:
+Open GitHub Copilot chat and invoke the skill:
 
-```bash
-claude
-> /speckit.my-ext.hello world
+```text
+/speckit-my-ext-hello world
 ```
 
-The command will be available in `.claude/commands/speckit.my-ext.hello.md`.
+The generated skill is available in
+`.github/skills/speckit-my-ext-hello/SKILL.md`. This invocation belongs in
+Copilot chat, not in your terminal.
 
 ---
 
@@ -193,7 +205,6 @@ of `provides.commands`, `provides.templates`, `provides.scripts`, `hooks`, or
 - `name`: Command name (must match `speckit.{ext-id}.{command}`)
 - `file`: Path to command file (relative to extension root)
 - `description`: Command description (optional)
-- `aliases`: Alternative command names (optional, array; each must match `speckit.{ext-id}.{command}`)
 
 **Template object**:
 
@@ -295,9 +306,13 @@ echo "Running with args: $args"
 
 ### Referencing other commands
 
-A command body is a *template* that Spec Kit renders once per agent. Different agents invoke commands with different surface syntax — for example `/speckit.plan` (dot separator) or `/speckit-plan` (hyphen separator). Some agents also use different prefixes in skills mode (e.g. Kimi `/skill:speckit-plan`, Codex/ZCode `$speckit-plan`). So when you reference a sibling command from a body, **do not hard-code a literal invocation** like `/speckit.my-ext.prepare`. A literal is correct for exactly one agent and breaks on the rest.
+A command body is a *template* that Spec Kit renders as a Copilot skill.
+When referencing another command from that body, **do not hard-code its
+invocation**. Use a command-reference token so Spec Kit renders the correct
+skill syntax and the extension remains portable.
 
-Instead use the agent-neutral token `__SPECKIT_COMMAND_<NAME>__`. Spec Kit resolves it to a `/speckit<separator>...` invocation using the active integration's `invoke_separator` (and integrations may post-process that further in skills output).
+Use the token `__SPECKIT_COMMAND_<NAME>__`. In Copilot's skills layout,
+Spec Kit resolves it to a `/speckit-...` invocation.
 
 Encode the command name in upper case, dropping the `speckit.` prefix and turning each dotted segment separator into an underscore. A hyphen inside a segment is kept as a hyphen:
 
@@ -308,7 +323,10 @@ Encode the command name in upper case, dropping the `speckit.` prefix and turnin
 | `speckit.git.commit.md` | `__SPECKIT_COMMAND_GIT_COMMIT__` |
 | `speckit.agent-context.update.md` | `__SPECKIT_COMMAND_AGENT-CONTEXT_UPDATE__` |
 
-The resolver maps each underscore back to the active agent's separator. An underscore separates segments and a hyphen belongs to the segment it sits in, so `AGENT-CONTEXT_UPDATE` is the two segments `agent-context` and `update` rather than three.
+An underscore separates command segments and a hyphen belongs to the segment
+it sits in, so `AGENT-CONTEXT_UPDATE` is the two segments `agent-context` and
+`update` rather than three. Copilot renders this as
+`/speckit-agent-context-update`.
 
 **Example** — a command body that points the user at the next step:
 
@@ -316,21 +334,12 @@ The resolver maps each underscore back to the active agent's separator. An under
 Once the assessment exists, the next step is `__SPECKIT_COMMAND_BUG_FIX__ slug=<slug>`.
 ```
 
-This renders as `/speckit.bug.fix slug=<slug>` for a slash-based agent, `/speckit-bug-fix slug=<slug>` for a skills-based agent, and so on — the author writes it once and it stays portable. The first-party `bug` and `git` extensions use this token exclusively; see `extensions/bug/commands/` for working examples.
-
-> **Skills mode.** Token resolution runs in both paths, so the token is safe to
-> use either way. Command files go through the command-rendering path
-> (`CommandRegistrar`). Skill bodies go through `_resolve_command_ref_tokens` in
-> `_register_extension_skills`, which resolves the same token shape against the
-> active skill style, so `__SPECKIT_COMMAND_BUG_FIX__` renders as:
->
-> | Agent | Rendered |
-> | --- | --- |
-> | Codex, ZCode, Command Code | `$speckit-bug-fix` |
-> | Claude, Copilot, Cursor, Devin, Droid, Grok and the other slash agents | `/speckit-bug-fix` |
-> | Kimi | `/skill:speckit-bug-fix` |
->
-> Anything else falls through to the integration's own `build_command_invocation`.
+This renders as `/speckit-bug-fix slug=<slug>` in Copilot chat. The first-party
+`bug` and `git` extensions use this token exclusively; see
+`extensions/bug/commands/` for working examples.
+
+For other integrations' invocation formats, see the shared
+[command invocation reference](../integrations/cli.md#command-invocation).
 
 ### Script Path Rewriting
 
@@ -500,7 +509,8 @@ The following `.gitignore` features are **not applicable** in this context:
 
 ### Manual Testing
 
-1. **Create test extension**
+1. **Create test extension** in a project configured for
+   [Copilot skills](../integrations/copilot.md#setup).
 2. **Install locally**:
 
    ```bash
@@ -513,11 +523,11 @@ The following `.gitignore` features are **not applicable** in this context:
    specify extension list
    ```
 
-4. **Test commands** with your AI agent
-5. **Check command registration**:
+4. **Test skills** in Copilot chat, for example `/speckit-my-ext-hello world`.
+5. **Check skill registration**:
 
    ```bash
-   ls .claude/commands/speckit.my-ext.*
+   ls .github/skills/speckit-my-ext-*/SKILL.md
    ```
 
 6. **Remove extension**:
@@ -603,7 +613,7 @@ Submit to the community catalog for public discovery:
    - Users copy the entry to their own `catalog.json`
    - Users install with: `specify extension add my-ext` (from their catalog)
 
-See the [Extension Publishing Guide](EXTENSION-PUBLISHING-GUIDE.md) for detailed submission instructions.
+See the [Extension Publishing Guide](publishing.md) for detailed submission instructions.
 
 ---
 
@@ -759,19 +769,19 @@ hooks:
 
 **Error**: `Extension requires spec-kit >=0.2.0`
 
-- **Fix**: Upgrade Spec Kit using the [Upgrade Guide](../docs/upgrade.md). `uv tool install specify-cli --force --from git+https://github.com/github/spec-kit.git` remains available as a source-install fallback. If you installed from PyPI and want to stay on that route, follow the [PyPI upgrade guidance](../docs/install/pypi.md#upgrade).
+- **Fix**: Upgrade Spec Kit using the [Upgrade Guide](../upgrade.md). `uv tool install specify-cli --force --from git+https://github.com/github/spec-kit.git` remains available as a source-install fallback. If you installed from PyPI and want to stay on that route, follow the [PyPI upgrade guidance](../install/pypi.md#upgrade).
 
 **Error**: `Command file not found`
 
 - **Fix**: Ensure command files exist at paths specified in manifest
 
-### Commands not registered
+### Skills not registered
 
-**Symptom**: Commands don't appear in AI agent
+**Symptom**: Skills don't appear in GitHub Copilot chat
 
 **Check**:
 
-1. `.claude/commands/` directory exists
+1. The generated skill exists at `.github/skills/speckit-my-ext-hello/SKILL.md`
 2. Extension installed successfully
 3. Commands registered in registry:
 
@@ -779,7 +789,9 @@ hooks:
    cat .specify/extensions/.registry
    ```
 
-**Fix**: Reinstall extension to trigger registration
+**Fix**: Confirm Copilot is configured for the
+[skills layout](../integrations/copilot.md#default-skills-layout), then
+reinstall the extension to trigger registration.
 
 ### Config not loading
 
@@ -807,3 +819,5 @@ hooks:
 4. **Iterate** based on feedback
 
 Happy extending! 🚀
+
+> Agent invocation examples on this page use GitHub Copilot's default skills syntax (`/speckit-*`). For other integrations and modes, see [Command invocation](../integrations/cli.md#command-invocation).