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

{specify_cli-1.2.4 → specify_cli-1.2.5}/.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.5}/.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.5}/.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.5}/CHANGELOG.md

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.2.4
+Version: 1.2.5
 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.5}/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.5}/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.5}/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.5}/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.5}/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-DEVELOPMENT-GUIDE.md → specify_cli-1.2.5/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).

specify_cli-1.2.4/extensions/EXTENSION-USER-GUIDE.md → specify_cli-1.2.5/docs/extensions/overview.md

@@ -1,4 +1,4 @@
-# Extension User Guide
+# Extensions Overview
 
 Complete guide for using Spec Kit extensions to enhance your workflow.
 
@@ -68,8 +68,8 @@ specify extension add jira
 vim .specify/extensions/jira/jira-config.yml
 
 # 5. Use it
-# (Commands are now available in Claude Code)
-/speckit.jira.specstoissues
+# (Skills are now available in GitHub Copilot)
+/speckit-jira-specstoissues
 ```
 
 ---
@@ -179,45 +179,25 @@ Jira Integration (v1.0.0)
   Create Jira Epics, Stories, and Issues from spec-kit artifacts
 
 Provided commands:
-  • speckit.jira.specstoissues - Create Jira hierarchy from spec and tasks
-  • speckit.jira.discover-fields - Discover Jira custom fields for configuration
-  • speckit.jira.sync-status - Sync task completion status to Jira
+  • speckit-jira-specstoissues - Create Jira hierarchy from spec and tasks
+  • speckit-jira-discover-fields - Discover Jira custom fields for configuration
+  • speckit-jira-sync-status - Sync task completion status to Jira
 
 ⚠  Configuration may be required
    Check: .specify/extensions/jira/
 ```
 
-Command names are listed the way your agent registers them. Skills-based integrations such as Claude Code and Codex, projects initialized with `--integration-options="--skills"`, and agents such as Cline, Forge, and Junie show hyphenated names (for example `speckit-jira-specstoissues`).
-
-### Automatic Agent Skill Registration
-
-If your project uses a skills-based integration (e.g., `--integration claude`, `--integration codex`) or was initialized with `--integration-options="--skills"`, extension commands are **automatically registered as agent skills** during installation. This ensures that extensions are discoverable by agents that use the [agentskills.io](https://agentskills.io) skill specification.
-
-```text
-✓ Extension installed successfully!
-
-Jira Integration (v1.0.0)
-  ...
-
-✓ 3 agent skill(s) auto-registered
-```
-
-When an extension is removed, its corresponding skills are also cleaned up automatically. Pre-existing skills that were manually customized are never overwritten.
-
 ---
 
 ## Using Extensions
 
 ### Using Extension Commands
 
-Extensions add commands that appear in your coding agent (Claude Code):
+Extensions add skills that appear in GitHub Copilot:
 
 ```text
-# In Claude Code
-> /speckit.jira.specstoissues
-
-# Or use a namespaced alias (if provided)
-> /speckit.jira.sync
+# In GitHub Copilot
+> /speckit-jira-specstoissues
 ```
 
 ### Extension Configuration
@@ -243,21 +223,21 @@ vim .specify/extensions/jira/jira-config.yml
 
 Some extensions provide hooks that execute after core commands:
 
-**Example**: Jira extension hooks into `/speckit.tasks`
+**Example**: Jira extension hooks into `/speckit-tasks`
 
 ```text
 # Run core command
-> /speckit.tasks
+> /speckit-tasks
 
 # Output includes:
 ## Extension Hooks
 
 **Optional Hook**: jira
-Command: `/speckit.jira.specstoissues`
+Command: `/speckit-jira-specstoissues`
 Description: Automatically create Jira hierarchy after task generation
 
 Prompt: Create Jira issues from tasks?
-To execute: `/speckit.jira.specstoissues`
+To execute: `/speckit-jira-specstoissues`
 ```
 
 You can then choose to run the hook or skip it.
@@ -348,7 +328,7 @@ Extensions can have multiple configuration files:
 ```text
 .specify/extensions/jira/
 ├── jira-config.yml           # Main config (version controlled)
-├── jira-config.local.yml     # Local overrides (gitignored)
+├── local-config.yml         # Local overrides (gitignored)
 └── jira-config.template.yml  # Template (reference)
 ```
 
@@ -358,7 +338,7 @@ Configuration is merged in this order (highest priority last):
 
 1. **Extension defaults** (from `extension.yml`)
 2. **Project config** (`jira-config.yml`)
-3. **Local overrides** (`jira-config.local.yml`)
+3. **Local overrides** (`local-config.yml`)
 4. **Environment variables** (`SPECKIT_JIRA_*`)
 
 ### Example: Jira Configuration
@@ -374,7 +354,7 @@ defaults:
     labels: ["spec-driven"]
 ```
 
-**Local override** (`.specify/extensions/jira/jira-config.local.yml`):
+**Local override** (`.specify/extensions/jira/local-config.yml`):
 
 ```yaml
 project:
@@ -805,11 +785,11 @@ specify extension add --dev /path/to/extension
 **Solutions**:
 
 1. Check extension is enabled: `specify extension list`
-2. Restart coding agent (Claude Code)
-3. Check command file exists:
+2. Restart GitHub Copilot
+3. Check the skill file exists:
 
    ```bash
-   ls .claude/commands/speckit.jira.*.md
+   ls .github/skills/speckit-jira-*/SKILL.md
    ```
 
 4. Reinstall extension
@@ -868,7 +848,7 @@ specify extension add --dev /path/to/extension
 
 - `.specify/extensions/.cache/` (catalog cache)
 - `.specify/extensions/.backup/` (config backups)
-- `.specify/extensions/*/*.local.yml` (local overrides)
+- `.specify/extensions/*/local-config.yml` (local overrides)
 - `.specify/extensions/.registry` (installation state)
 
 Add to `.gitignore`:
@@ -876,7 +856,7 @@ Add to `.gitignore`:
 ```gitignore
 .specify/extensions/.cache/
 .specify/extensions/.backup/
-.specify/extensions/*/*.local.yml
+.specify/extensions/*/local-config.yml
 .specify/extensions/.registry
 ```
 
@@ -907,7 +887,7 @@ To install: `specify extension add jira`
 Use local config for development:
 
 ```yaml
-# .specify/extensions/jira/jira-config.local.yml
+# .specify/extensions/jira/local-config.yml
 project:
   key: "DEVTEST"  # Your test project
 
@@ -966,9 +946,9 @@ Document extension usage in your project:
 ## Working with Jira
 
 After creating tasks, sync to Jira:
-1. Run `/speckit.tasks` to generate tasks
-2. Run `/speckit.jira.specstoissues` to create Jira issues
-3. Run `/speckit.jira.sync-status` to update status
+1. Run `/speckit-tasks` to generate tasks
+2. Run `/speckit-jira-specstoissues` to create Jira issues
+3. Run `/speckit-jira-sync-status` to update status
 ```
 
 ---
@@ -1020,11 +1000,13 @@ After creating tasks, sync to Jira:
 ## Support
 
 - **Extension Issues**: Report to extension repository (see `specify extension info`)
-- **Spec Kit Issues**: <https://github.com/statsperform/spec-kit/issues>
-- **Extension Catalog**: <https://github.com/statsperform/spec-kit/tree/main/extensions>
-- **Documentation**: See EXTENSION-DEVELOPMENT-GUIDE.md and EXTENSION-PUBLISHING-GUIDE.md
+- **Spec Kit Issues**: <https://github.com/github/spec-kit/issues>
+- **Extension Catalog**: <https://github.com/github/spec-kit/tree/main/extensions>
+- **Documentation**: See [Developing extensions](developing.md) and [Extension Publishing Guide](publishing.md)
 
 ---
 
 *Last Updated: 2026-01-28*
 *Spec Kit Version: 0.1.0*
+
+> 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).

specify_cli-1.2.4/extensions/EXTENSION-PUBLISHING-GUIDE.md → specify_cli-1.2.5/docs/extensions/publishing.md

@@ -130,7 +130,7 @@ specify extension add <extension-name> --from https://github.com/your-org/spec-k
 
 ### Understanding the Catalogs
 
-Spec Kit uses a dual-catalog system. For details about how catalogs work, see the main [Extensions README](README.md#extension-catalogs).
+Spec Kit uses a dual-catalog system. For details about how catalogs work, see the main [Extensions README](https://github.com/github/spec-kit/blob/main/extensions/README.md#extension-catalogs).
 
 **For extension publishing**: All community extensions are listed in `extensions/catalog.community.json`. Users browse this catalog and copy extensions they trust into their own `catalog.json`.
 
@@ -147,7 +147,7 @@ To submit your extension to the community catalog, file a new issue using the **
 - Testing confirmation
 
 > [!IMPORTANT]
-> Do **not** open a pull request directly to edit `extensions/catalog.community.json`. All community extension submissions must go through the issue template so a maintainer can review the entry and update the catalog.
+> Do **not** open a pull request directly to edit `extensions/catalog.community.json`. All community extension submissions must go through the issue template. Submissions that do not use the issue template will be closed, and you will be asked to resubmit using it.
 
 ### What Happens After You Submit
 
@@ -303,7 +303,7 @@ A: Extensions should be free and open-source. Commercial support/services are al
 
 - **Catalog Issues**: <https://github.com/statsperform/spec-kit/issues>
 - **Extension Template**: <https://github.com/statsperform/spec-kit-extension-template> (coming soon)
-- **Development Guide**: See EXTENSION-DEVELOPMENT-GUIDE.md
+- **Development Guide**: See [Developing extensions](developing.md)
 - **Community**: Discussions and Q&A
 
 ---

{specify_cli-1.2.4 → specify_cli-1.2.5}/docs/integrations/vibe.md

@@ -67,6 +67,14 @@ unsupported handlers are skipped with a warning.
 `--integration-options="--events false"` disables Spec Kit event handlers.
 See [runtime events](cli.md#runtime-events).
 
+Spec Kit refreshes and removes only the `[[hooks]]` entries it wrote, which
+carry `speckit_marker = true`. Each entry ends after its last TOML line and the
+blank lines right after it, so a comment that follows a Spec Kit entry, such as
+a note above your own hook, stays in the file. If removing Spec Kit's entries
+leaves only comments and blank lines, Spec Kit deletes `.vibe/hooks.toml`, and
+those comments are deleted with it. Spec Kit applies the same rule to Codex's
+`.codex/config.toml`.
+
 ## Workflow Dispatch
 
 Workflow steps use `vibe -p <prompt>` and request `--output json` for structured

{specify_cli-1.2.4 → specify_cli-1.2.5}/docs/reference/catalogs.md

@@ -139,7 +139,7 @@ Use the component-specific publishing guidance when authoring catalog entries:
 | Component type | Publishing guidance |
 | --- | --- |
 | Integrations | [Integration catalog contributions](../integrations/contributing.md) |
-| Extensions | [Extension Publishing Guide](https://github.com/github/spec-kit/blob/main/extensions/EXTENSION-PUBLISHING-GUIDE.md) |
+| Extensions | [Extension Publishing Guide](../extensions/publishing.md) |
 | Presets | [Preset Publishing Guide](https://github.com/github/spec-kit/blob/main/presets/PUBLISHING.md) |
 | Workflows | [Workflow Publishing Guide](https://github.com/github/spec-kit/blob/main/workflows/PUBLISHING.md) |
 | Workflow steps | [Community workflow step types](../community/workflow-steps.md) |