diff --git a/docs/community/extensions.md b/docs/community/extensions.md
index 58b7a56c4d..cf2acb9b23 100644
--- a/docs/community/extensions.md
+++ b/docs/community/extensions.md
@@ -45,7 +45,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Azure Cosmos DB | Best-practice Azure Cosmos DB code generation and review for any AI coding agent | `code` | Read+Write | [spec-kit-cosmosdb](https://github.com/AzureCosmosDB/spec-kit-cosmosdb) |
 | Azure DevOps Integration | Sync user stories and tasks to Azure DevOps work items using OAuth authentication | `integration` | Read+Write | [spec-kit-azure-devops](https://github.com/pragya247/spec-kit-azure-devops) |
 | BDD | Convert specs to Gherkin scenarios, scaffold step definitions, and verify acceptance test coverage | `process` | Read+Write | [spec-kit-bdd](https://github.com/RSginer/spec-kit-bdd) |
-| Blueprint | Stay code-literate in AI-driven development: review a complete code blueprint for every task from spec artifacts before /speckit.implement runs | `docs` | Read+Write | [spec-kit-blueprint](https://github.com/chordpli/spec-kit-blueprint) |
+| Blueprint | Stay code-literate in AI-driven development: review a complete code blueprint for every task from spec artifacts before /speckit-implement runs | `docs` | Read+Write | [spec-kit-blueprint](https://github.com/chordpli/spec-kit-blueprint) |
 | Blueprint Index — Living Architecture Map | A living architecture map for spec-driven projects, kept honest by a deterministic, low-friction, machine-first CI gate (JSON, self-healable) that blocks only when the map contradicts the specs or code. Brownfield or greenfield. | `process` | Read+Write | [spec-kit-blueprint](https://github.com/ogil109/spec-kit-blueprint) |
 | Branch Convention | Configurable branch and folder naming conventions for /specify with presets and custom patterns | `process` | Read+Write | [spec-kit-branch-convention](https://github.com/Quratulain-bilal/spec-kit-branch-convention) |
 | Brownfield Bootstrap | Bootstrap spec-kit for existing codebases — auto-discover architecture and adopt SDD incrementally | `process` | Read+Write | [spec-kit-brownfield](https://github.com/Quratulain-bilal/spec-kit-brownfield) |
@@ -69,7 +69,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | 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) |
 | Evaluator Contract | Provider-neutral evaluator contract for evidence, provenance, uncertainty, and recovery across Spec-Driven Development phases. | `process` | Read+Write | [spec-kit-evaluator](https://github.com/electrohire/spec-kit-evaluator) |
 | Extensify | Create and validate extensions and extension catalogs | `process` | Read+Write | [extensify](https://github.com/mnriem/spec-kit-extensions/tree/main/extensify) |
-| Figma Starter | Turns a Figma section's screens into Figma-derived specs, and an OpenAPI/Swagger document into an entity model plus per-page UI-to-API bindings, then hands off to /speckit.specify | `docs` | Read+Write | [spec-kit-figma-starter](https://github.com/OmneWave/spec-kit-figma-starter) |
+| Figma Starter | Turns a Figma section's screens into Figma-derived specs, and an OpenAPI/Swagger document into an entity model plus per-page UI-to-API bindings, then hands off to /speckit-specify | `docs` | Read+Write | [spec-kit-figma-starter](https://github.com/OmneWave/spec-kit-figma-starter) |
 | 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) |
 | Fleet Orchestrator | Orchestrate a full feature lifecycle with human-in-the-loop gates across all SpecKit phases | `process` | Read+Write | [spec-kit-fleet](https://github.com/sharathsatish/spec-kit-fleet) |
@@ -85,7 +85,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | 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) |
 | Jira Mirror | Spec Kit ↔ Jira bridge for team-managed and company-managed projects: configurable workflows & hierarchies (Scrum/SAFe), multi-project, idempotent and fail-closed. macOS/Linux/Windows. | `integration` | Read+Write | [spec-kit-jira-mirror](https://github.com/Fyloss/spec-kit-jira-mirror) |
-| Keel Discovery | Evidence-backed discovery upstream of /speckit.specify, plus round-trip drift auditing after implementation | `process` | Read+Write | [spec-kit-keel](https://github.com/keeldiscovery/spec-kit-keel) |
+| Keel Discovery | Evidence-backed discovery upstream of /speckit-specify, plus round-trip drift auditing after implementation | `process` | Read+Write | [spec-kit-keel](https://github.com/keeldiscovery/spec-kit-keel) |
 | 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 | Automatically mirror your spec-kit specs into Linear — one issue per spec, a sub-issue per task phase, kept in sync as you work. | `integration` | Read+Write | [spec-kit-linear-sync](https://github.com/ashbrener/spec-kit-linear-sync) |
 | Linear Weave | Weave Spec Kit into Linear: pull requirements, mirror tasks.md into sub-issues, sync statuses | `integration` | Read+Write | [spec-kit-linear-weave](https://github.com/tonydwoodhouse/spec-kit-linear-weave) |
@@ -116,7 +116,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | 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-) |
-| Pre-Spec Cards | Card-based pre-spec thinking: paste an idea, get your card plus the paths you'd miss, then play each through — story, snags, trade-offs, difficulty vs payoff — before /speckit.specify | `process` | Read+Write | [pre-spec](https://github.com/bendlikeabamboo/pre-spec) |
+| Pre-Spec Cards | Card-based pre-spec thinking: paste an idea, get your card plus the paths you'd miss, then play each through — story, snags, trade-offs, difficulty vs payoff — before /speckit-specify | `process` | Read+Write | [pre-spec](https://github.com/bendlikeabamboo/pre-spec) |
 | Presetify | Create and validate presets and preset catalogs | `process` | Read+Write | [presetify](https://github.com/mnriem/spec-kit-extensions/tree/main/presetify) |
 | Product Definition as Code (PDaC) | Ground Spec Kit features in an accepted product definition, then verify citations across the delivery artifacts | `process` | Read+Write | [productshape](https://github.com/juangcarmona/productshape) |
 | Product Forge | Full product-lifecycle orchestrator for Spec Kit: research → product-spec → plan → tasks → implement → verify → test → release-readiness, across express/lite/standard/v-model modes with human-in-the-loop gates. | `process` | Read+Write | [speckit-product-forge](https://github.com/VaiYav/speckit-product-forge) |
@@ -129,7 +129,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | 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 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) |
+| 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 Governance | Generate project-governance projections from Spec Kit metadata | `process` | Read+Write | [spec-kit-agent-governance](https://github.com/bigsmartben/spec-kit-agent-governance) |
 | 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) |
@@ -159,7 +159,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | 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) |
+| Spec Validate | Comprehension validation, review gating, and approval state for spec-kit artifacts — staged quizzes, peer review SLA, and a hard gate before /speckit-implement | `process` | Read+Write | [spec-kit-spec-validate](https://github.com/aeltayeb/spec-kit-spec-validate) |
 | Spec2Cloud | Spec-driven workflow tuned for shipping to Azure | `process` | Read+Write | [spec2cloud](https://github.com/Azure-Samples/Spec2Cloud) |
 | SpecAssay Check | Gate 2 refuses silent gaps and emits a trace-manifest (trace-manifest.json). | `visibility` | Read+Write | [specassay](https://github.com/rdryfoos/specassay) |
 | SpecJudge — right-size the model before you implement | Recommends the model that fits your tasks, citing the spec fragment behind every level. | `process` | Read-only | [SpecJudge](https://github.com/JoaquinRuiz/SpecJudge) |
@@ -189,7 +189,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Version Guard | Verify tech stack versions against live npm registries before planning and implementation | `process` | Read-only | [spec-kit-version-guard](https://github.com/KevinBrown5280/spec-kit-version-guard) |
 | Vurnix Honest Gate | Deterministic three-state honest gate for AI-written code: compile + phantom-import + honest test count in one verdict, executed as code — not as agent self-review. PASS/BLOCK/UNPROVEN by exit code. | `process` | Read-only | [vurnix-spec-kit](https://github.com/shiersa/vurnix-spec-kit) |
 | What-if Analysis | Preview the downstream impact (complexity, effort, tasks, risks) of requirement changes before committing to them | `visibility` | Read-only | [spec-kit-whatif](https://github.com/DevAbdullah90/spec-kit-whatif) |
-| Wireframe Visual Feedback Loop | SVG wireframe generation, review, and sign-off for spec-driven development. Approved wireframes become spec constraints honored by /speckit.plan, /speckit.tasks, and /speckit.implement | `visibility` | Read+Write | [spec-kit-extension-wireframe](https://github.com/TortoiseWolfe/spec-kit-extension-wireframe) |
+| Wireframe Visual Feedback Loop | SVG wireframe generation, review, and sign-off for spec-driven development. Approved wireframes become spec constraints honored by /speckit-plan, /speckit-tasks, and /speckit-implement | `visibility` | Read+Write | [spec-kit-extension-wireframe](https://github.com/TortoiseWolfe/spec-kit-extension-wireframe) |
 | Work IQ | Integrate Microsoft 365 organizational knowledge into spec-driven development workflows | `integration` | Read-only | [spec-kit-workiq](https://github.com/sakitA/spec-kit-workiq) |
 | 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) |
diff --git a/docs/community/presets.md b/docs/community/presets.md
index 72128f987c..e0ccd567dc 100644
--- a/docs/community/presets.md
+++ b/docs/community/presets.md
@@ -13,8 +13,8 @@ The following community-contributed presets customize how Spec Kit behaves — o
 | Architecture Governance | Adds secure architecture, STRIDE/CAPEC threat modeling, arc42/S-ADR guidance, Zero Trust, SAMM, BSI cloud assurance, audit evidence, and provider-neutral model routing. | 14 templates, 3 commands | — | [spec-kit-preset-architecture-governance](https://github.com/hindermath/spec-kit-preset-architecture-governance) |
 | Autonomous Run Governance | Adds permission-bounded autonomous delivery with validated delivery sets, semantic phase completion, and lifecycle-bound exact-head evidence. | 15 templates, 5 commands, 11 scripts | — | [spec-kit-preset-autonomous-run-governance](https://github.com/hindermath/spec-kit-preset-autonomous-run-governance) |
 | Canon Core | Adapts original Spec Kit workflow to work together with Canon extension | 2 templates, 8 commands | — | [spec-kit-canon](https://github.com/maximiliamus/spec-kit-canon) |
-| Claude AskUserQuestion | Upgrades `/speckit.clarify` and `/speckit.checklist` on Claude Code from Markdown-table prompts to the native AskUserQuestion picker, with a recommended option and reasoning on every question | 2 commands | — | [spec-kit-preset-claude-ask-questions](https://github.com/0xrafasec/spec-kit-preset-claude-ask-questions) |
-| Closed Vocabulary Check | Adds a pass to /speckit.analyze that flags closed sets of values enumerated more than once with different members, and reports its own coverage. | 1 command | — | [spec-kit-preset-closed-vocabulary](https://github.com/yunusdim/spec-kit-preset-closed-vocabulary) |
+| Claude AskUserQuestion | Upgrades `/speckit-clarify` and `/speckit-checklist` on Claude Code from Markdown-table prompts to the native AskUserQuestion picker, with a recommended option and reasoning on every question | 2 commands | — | [spec-kit-preset-claude-ask-questions](https://github.com/0xrafasec/spec-kit-preset-claude-ask-questions) |
+| Closed Vocabulary Check | Adds a pass to /speckit-analyze that flags closed sets of values enumerated more than once with different members, and reports its own coverage. | 1 command | — | [spec-kit-preset-closed-vocabulary](https://github.com/yunusdim/spec-kit-preset-closed-vocabulary) |
 | Command Density | Compacts the nine core Spec Kit command prompts while preserving scripts, handoffs, placeholders, hook output blocks, and rule structure | 9 commands | — | [spec-kit-preset-command-density](https://github.com/Xopoko/spec-kit-preset-command-density) |
 | Cross-Platform Governance | Adds Bash/PowerShell parity, read-only checks, path and native-override review, Unix man pages, bilingual PowerShell help, and provider-neutral model routing. | 9 templates, 3 commands | — | [spec-kit-preset-cross-platform-governance](https://github.com/hindermath/spec-kit-preset-cross-platform-governance) |
 | Explicit Task Dependencies | Adds explicit `(depends on T###)` dependency declarations and an Execution Wave DAG to tasks.md for parallel scheduling | 1 template, 1 command | — | [spec-kit-preset-explicit-task-dependencies](https://github.com/Quratulain-bilal/spec-kit-preset-explicit-task-dependencies) |
diff --git a/docs/concepts/complex-features.md b/docs/concepts/complex-features.md
index 4fe9ae85d1..0e9f0220d4 100644
--- a/docs/concepts/complex-features.md
+++ b/docs/concepts/complex-features.md
@@ -1,8 +1,8 @@
 # Handling Complex Features
 
-Large or complex features often run smoothly through `/speckit.specify`,
-`/speckit.plan`, and `/speckit.tasks`, then degrade during implementation. In
-the middle of a long `/speckit.implement` run, agents can start to lose track of
+Large or complex features often run smoothly through `/speckit-specify`,
+`/speckit-plan`, and `/speckit-tasks`, then degrade during implementation. In
+the middle of a long `/speckit-implement` run, agents can start to lose track of
 the plan, ignore tasks, or hallucinate — usually right before or after context
 compaction is triggered.
 
@@ -11,37 +11,37 @@ implementation run tries to hold the entire feature in context, the model
 degrades as the window fills. The fix is to scope each run so it stays well
 within context limits.
 
-The `/speckit.implement` command accepts free-form user input that the agent
+The `/speckit-implement` command accepts free-form user input that the agent
 must consider before proceeding. This means you can scope each run without any
 tooling changes.
 
 ## Option 1: Limit How Many Tasks Run Per Invocation
 
-Instead of letting `/speckit.implement` run through every task at once, tell it
+Instead of letting `/speckit-implement` run through every task at once, tell it
 to stop early:
 
 ```text
-/speckit.implement only execute tasks T001-T010, then stop and report progress
+/speckit-implement only execute tasks T001-T010, then stop and report progress
 ```
 
 or scope by phase:
 
 ```text
-/speckit.implement only execute the Setup phase, then stop
+/speckit-implement only execute the Setup phase, then stop
 ```
 
 Because completed tasks are marked `[X]` in `tasks.md`, the next
-`/speckit.implement` invocation picks up where you left off. This keeps each run
+`/speckit-implement` invocation picks up where you left off. This keeps each run
 well within context limits.
 
 ## Option 2: Instruct the Agent to Use Sub-Agents
 
 If your coding agent supports sub-agents (for example, GitHub Copilot CLI or the
-GitHub Copilot extension for VS Code), you can instruct `/speckit.implement` to
+GitHub Copilot extension for VS Code), you can instruct `/speckit-implement` to
 delegate individual tasks:
 
 ```text
-/speckit.implement delegate each parallel [P] task to a sub-agent
+/speckit-implement delegate each parallel [P] task to a sub-agent
 ```
 
 Each sub-agent gets a focused context — one task plus the relevant plan
@@ -53,7 +53,7 @@ in the main session.
 For very large features, combine scoping and delegation:
 
 ```text
-/speckit.implement execute only the Core phase, delegate [P] tasks to sub-agents
+/speckit-implement execute only the Core phase, delegate [P] tasks to sub-agents
 ```
 
 ## Option 4: Decompose the Feature Into Smaller Specs
diff --git a/docs/concepts/spec-of-specs.md b/docs/concepts/spec-of-specs.md
index 2439798e01..e45148781e 100644
--- a/docs/concepts/spec-of-specs.md
+++ b/docs/concepts/spec-of-specs.md
@@ -1,7 +1,7 @@
 # Spec of Specs
 
 When a feature is too large to run through a single
-`/speckit.specify` → `/speckit.plan` → `/speckit.tasks` → `/speckit.implement`
+`/speckit-specify` → `/speckit-plan` → `/speckit-tasks` → `/speckit-implement`
 cycle without the model losing track mid-implementation, you can break it into a
 **roadmap** of smaller, independently-specified sub-features. This is the "spec of
 specs" approach: one up-front pass decomposes a massive feature into self-contained
@@ -10,7 +10,7 @@ specs, and each of those runs through its own specify/plan/tasks/implement cycle
 > **When to reach for this.** Decomposition adds the most overhead of any strategy
 > in [Handling Complex Features](complex-features.md). Use it **only when the lighter
 > options there are insufficient** — first try limiting how many tasks run per
-> `/speckit.implement` invocation, then sub-agent delegation, then a combination.
+> `/speckit-implement` invocation, then sub-agent delegation, then a combination.
 > Reach for a spec of specs only when even a single phase is too large to handle in
 > one run.
 
@@ -40,7 +40,7 @@ Treat this as a lightweight planning conversation with your agent, not a full sp
 
 The roadmap is deliberately shallow: it names and orders the sub-features but does
 **not** design them. The design happens when each slice runs through its own
-`/speckit.specify`.
+`/speckit-specify`.
 
 ## The roadmap artifact
 
@@ -78,10 +78,10 @@ With the roadmap in hand, work through the entries one at a time using the norma
 Spec Kit flow — nothing new to learn:
 
 1. Pick the next roadmap entry whose dependencies are already `done` (or have none).
-2. Run `/speckit.specify` for just that slice, describing only its intent and scope
+2. Run `/speckit-specify` for just that slice, describing only its intent and scope
    from the roadmap entry. Because the slice is bounded, its spec, plan, and tasks
    stay well within the context window.
-3. Run `/speckit.plan`, `/speckit.tasks`, and `/speckit.implement` for that slice as
+3. Run `/speckit-plan`, `/speckit-tasks`, and `/speckit-implement` for that slice as
    usual.
 4. Mark the roadmap entry `done` and move to the next one.
 
diff --git a/docs/guides/evolving-specs.md b/docs/guides/evolving-specs.md
index 17a91298ea..eb064e4f80 100644
--- a/docs/guides/evolving-specs.md
+++ b/docs/guides/evolving-specs.md
@@ -23,14 +23,14 @@ For the conceptual model definitions, see
 Use flow-forward when each feature directory should remain a historical record.
 
 When you add another feature or make a substantial follow-up change, create a
-new feature spec through your installed `/speckit.specify` command and continue
+new feature spec through your installed `/speckit-specify` command and continue
 through the standard flow:
 
-1. Run `/speckit.specify` to create a new feature directory under `specs/`.
-2. Run `/speckit.plan` to define the implementation approach.
-3. Run `/speckit.tasks` to derive the work breakdown.
-4. Run `/speckit.implement` and review the resulting code and artifact diffs.
-5. Run `/speckit.converge` to verify completeness and generate tasks for remaining gaps. If tasks are appended, repeat `/speckit.implement` and `/speckit.converge` until the feature is fully complete.
+1. Run `/speckit-specify` to create a new feature directory under `specs/`.
+2. Run `/speckit-plan` to define the implementation approach.
+3. Run `/speckit-tasks` to derive the work breakdown.
+4. Run `/speckit-implement` and review the resulting code and artifact diffs.
+5. Run `/speckit-converge` to verify completeness and generate tasks for remaining gaps. If tasks are appended, repeat `/speckit-implement` and `/speckit-converge` until the feature is fully complete.
 
 The previous feature directory remains intact for audit, comparison, or
 explaining how the project reached its current state. Use clear feature names or
@@ -47,15 +47,15 @@ spec:
 
 1. Start from a clean working tree or a dedicated branch so every generated
    change is reviewable.
-2. Update `spec.md` with `/speckit.clarify` or an explicit edit.
-3. Rerun `/speckit.plan` or revise `plan.md` so the technical approach matches
+2. Update `spec.md` with `/speckit-clarify` or an explicit edit.
+3. Rerun `/speckit-plan` or revise `plan.md` so the technical approach matches
    the revised spec.
-4. Rerun `/speckit.tasks` or revise `tasks.md` so implementation work matches
+4. Rerun `/speckit-tasks` or revise `tasks.md` so implementation work matches
    the revised plan.
-5. Run `/speckit.analyze` before implementation resumes to catch gaps between
+5. Run `/speckit-analyze` before implementation resumes to catch gaps between
    the spec, plan, and tasks.
-6. Run `/speckit.implement`, then review the code and artifact diffs together.
-7. Run `/speckit.converge` to assess completion and append any remaining work to `tasks.md`. If tasks are appended, repeat `/speckit.implement` and `/speckit.converge` until the feature is fully complete.
+6. Run `/speckit-implement`, then review the code and artifact diffs together.
+7. Run `/speckit-converge` to assess completion and append any remaining work to `tasks.md`. If tasks are appended, repeat `/speckit-implement` and `/speckit-converge` until the feature is fully complete.
 
 Preserve important implementation rationale before replacing derived artifacts.
 If a plan or task list contains decisions that still matter, carry them forward
@@ -74,7 +74,7 @@ the artifact set back into alignment:
 2. Decide whether it changes intended behavior, implementation strategy, task
    breakdown, or only code.
 3. Update any other artifacts that now disagree with the accepted direction.
-4. Run `/speckit.analyze` to check for gaps across `spec.md`, `plan.md`, and
+4. Run `/speckit-analyze` to check for gaps across `spec.md`, `plan.md`, and
    `tasks.md`.
 5. Continue implementation only after the artifact set describes the behavior
    and approach you want future contributors to trust.
diff --git a/docs/guides/existing-projects.md b/docs/guides/existing-projects.md
index 9736557316..73fc145755 100644
--- a/docs/guides/existing-projects.md
+++ b/docs/guides/existing-projects.md
@@ -39,11 +39,11 @@ first task is a repair, you can instead follow the
 use the [idea assessment quickstart](assessment.md). Neither process requires
 completing the SDD steps below first.
 
-Run `/speckit.constitution` with principles that are already true for the
+Run `/speckit-constitution` with principles that are already true for the
 repository or that the team has explicitly agreed to adopt:
 
 ```text
-/speckit.constitution Preserve public API compatibility. Follow the existing
+/speckit-constitution Preserve public API compatibility. Follow the existing
 service boundaries. Every database migration must include a rollback plan.
 Run the repository's established unit and integration test suites.
 ```
@@ -63,7 +63,7 @@ Describe both the requested outcome and the compatibility boundaries that must
 remain intact:
 
 ```text
-/speckit.specify Add CSV export to the existing orders page. Preserve current
+/speckit-specify Add CSV export to the existing orders page. Preserve current
 filters and authorization behavior. Export only the rows visible to the signed-in
 user, and do not change the existing JSON API response.
 ```
@@ -76,14 +76,14 @@ behavior.
 
 Continue through the normal workflow:
 
-1. Run `/speckit.clarify` to resolve uncertain behavior and compatibility
+1. Run `/speckit-clarify` to resolve uncertain behavior and compatibility
    requirements.
-2. Run `/speckit.plan` and verify that the proposed design reuses the existing
+2. Run `/speckit-plan` and verify that the proposed design reuses the existing
    architecture, dependencies, and test conventions.
-3. Run `/speckit.tasks`, then `/speckit.analyze` to check consistency before
+3. Run `/speckit-tasks`, then `/speckit-analyze` to check consistency before
    implementation.
-4. Run `/speckit.implement` and review code and artifact changes together.
-5. Run `/speckit.converge` to find remaining gaps. If it adds tasks, repeat
+4. Run `/speckit-implement` and review code and artifact changes together.
+5. Run `/speckit-converge` to find remaining gaps. If it adds tasks, repeat
    implementation and convergence until the feature is complete.
 
 For command details and optional quality gates, see the
diff --git a/docs/guides/monorepo.md b/docs/guides/monorepo.md
index 48abd1372c..a245c0cc2e 100644
--- a/docs/guides/monorepo.md
+++ b/docs/guides/monorepo.md
@@ -43,7 +43,7 @@ slash commands. Root resolution finds the nearest `.specify/`.
 
 ```bash
 cd apps/web
-# then run /speckit.specify, /speckit.plan, … in your agent
+# then run /speckit-specify, /speckit-plan, … in your agent
 ```
 
 ## Targeting a member project from the repo root
@@ -99,7 +99,7 @@ when it is present in the environment of the shell that runs those scripts.
   it is reliable there.
 - **Interactive agents:** whether an exported variable reaches the shell tool an
   agent uses is agent-specific. Export `SPECIFY_INIT_DIR` *before* launching the
-  agent, and verify once (e.g. run `/speckit.specify` and confirm the new feature
+  agent, and verify once (e.g. run `/speckit-specify` and confirm the new feature
   landed under the intended project's `specs/`).
 
 ## Git in a monorepo
@@ -117,7 +117,7 @@ when it is present in the environment of the shell that runs those scripts.
 ## Constitutions
 
 Each member project has its own `.specify/memory/constitution.md` and
-`/speckit.constitution` edits the local project's file. Spec Kit does not provide
+`/speckit-constitution` edits the local project's file. Spec Kit does not provide
 a built-in base/inheritance mechanism; if you want one constitution to reference
 shared rules elsewhere in the monorepo, you need to maintain that wiring yourself.
 Otherwise, duplicate or sync shared engineering rules per project.
diff --git a/docs/installation.md b/docs/installation.md
index a8a68fc992..93154a671c 100644
--- a/docs/installation.md
+++ b/docs/installation.md
@@ -138,16 +138,16 @@ This confirms that the `specify` command is available and reporting the expected
 
 After initialization, you should see the following commands available in your coding agent:
 
-- `/speckit.specify` - Create specifications
-- `/speckit.plan` - Generate implementation plans
-- `/speckit.tasks` - Break down into actionable tasks
-- `/speckit.implement` - Execute implementation tasks
-- `/speckit.analyze` - Validate cross-artifact consistency
-- `/speckit.clarify` - Identify and resolve ambiguities
-- `/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-specify` - Create specifications
+- `/speckit-plan` - Generate implementation plans
+- `/speckit-tasks` - Break down into actionable tasks
+- `/speckit-implement` - Execute implementation tasks
+- `/speckit-analyze` - Validate cross-artifact consistency
+- `/speckit-clarify` - Identify and resolve ambiguities
+- `/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
 
 Scripts are installed into a variant subdirectory matching the chosen script type:
 
diff --git a/docs/reference/agentic-assessment.md b/docs/reference/agentic-assessment.md
index d5d48515c5..e15f32cfc0 100644
--- a/docs/reference/agentic-assessment.md
+++ b/docs/reference/agentic-assessment.md
@@ -12,8 +12,8 @@ Install it from an initialized project's root:
 specify extension add assess
 ```
 
-Commands below use `/speckit.assess.*` notation. GitHub Copilot's default skills
-mode uses `/speckit-assess-*`; other integrations may use a different prefix.
+Commands below use GitHub Copilot's default skills notation, `/speckit-assess-*`.
+Other integrations may use a different prefix.
 See [Command invocation](integrations.md#command-invocation).
 
 ## Commands and artifacts
@@ -22,20 +22,20 @@ Every artifact is written under `.specify/assessments/<slug>/`.
 
 | Command | Purpose | Output |
 | --- | --- | --- |
-| `/speckit.assess.intake` | Capture an idea from text, a URL, a ticket, or a codebase pointer | `intake.md` |
-| `/speckit.assess.research` | Gather evidence for and against the idea, with sources and confidence | `research.md` |
-| `/speckit.assess.define` | Define users, the problem, goals, non-goals, metrics, and cost of inaction | `problem.md` |
-| `/speckit.assess.shape` | Compare concept-level options, appetite, and trade-offs | `concept.md` |
-| `/speckit.assess.decide` | Record a scorecard, verdict, rationale, and optional SDD handoff | `decision.md` |
+| `/speckit-assess-intake` | Capture an idea from text, a URL, a ticket, or a codebase pointer | `intake.md` |
+| `/speckit-assess-research` | Gather evidence for and against the idea, with sources and confidence | `research.md` |
+| `/speckit-assess-define` | Define users, the problem, goals, non-goals, metrics, and cost of inaction | `problem.md` |
+| `/speckit-assess-shape` | Compare concept-level options, appetite, and trade-offs | `concept.md` |
+| `/speckit-assess-decide` | Record a scorecard, verdict, rationale, and optional SDD handoff | `decision.md` |
 
 Pass the initial idea and a slug to intake, then reuse the slug:
 
 ```text
-/speckit.assess.intake "Let users work offline and sync when they reconnect." slug=offline-mode
-/speckit.assess.research slug=offline-mode
-/speckit.assess.define slug=offline-mode
-/speckit.assess.shape slug=offline-mode
-/speckit.assess.decide slug=offline-mode
+/speckit-assess-intake "Let users work offline and sync when they reconnect." slug=offline-mode
+/speckit-assess-research slug=offline-mode
+/speckit-assess-define slug=offline-mode
+/speckit-assess-shape slug=offline-mode
+/speckit-assess-decide slug=offline-mode
 ```
 
 ## Prerequisites and scope
@@ -92,7 +92,7 @@ discarded draft. See the
 ## Handoff and guardrails
 
 A `go` decision includes a handoff summary you can choose to pass to
-`/speckit.specify`. No lifecycle hooks install assessment as a prerequisite of
+`/speckit-specify`. No lifecycle hooks install assessment as a prerequisite of
 SDD, and non-software ideas need not enter SDD at all.
 
 Assessment commands write only within `.specify/assessments/<slug>/`; they do not
diff --git a/docs/reference/agentic-bugfix.md b/docs/reference/agentic-bugfix.md
index 0fad24388b..e8d01060dc 100644
--- a/docs/reference/agentic-bugfix.md
+++ b/docs/reference/agentic-bugfix.md
@@ -8,7 +8,7 @@ rather than repairing broken behavior, see
 [Idea Assessment](agentic-assessment.md).
 
 > [!NOTE]
-> Commands are written in `/speckit.bug.*` form throughout this page. GitHub Copilot's default skills mode uses `/speckit-bug-*`; some other agents use `$speckit-bug-*` (e.g. Codex, ZCode) or `/skill:speckit-bug-*` (e.g. Kimi). See [Command invocation](integrations.md#command-invocation).
+> Commands use GitHub Copilot's default skills form, `/speckit-bug-*`, throughout this page. Some other agents use `$speckit-bug-*` (e.g. Codex, ZCode) or `/skill:speckit-bug-*` (e.g. Kimi). See [Command invocation](integrations.md#command-invocation).
 
 The bug extension is a bundled, opt-in extension. Install it before using these commands:
 
@@ -16,42 +16,42 @@ The bug extension is a bundled, opt-in extension. Install it before using these
 specify extension add bug
 ```
 
-The three commands share a single handle — the **slug**, the per-bug directory name under `.specify/bugs/`. Supply it with `slug=<name>`; if omitted, `/speckit.bug.assess` asks for one (or generates a unique one in automated mode). Slugs are normalized to lowercase kebab-case. If an assessment already exists for a slug, an interactive run asks before overwriting it, while an automated run refuses and picks a new unique slug instead.
+The three commands share a single handle — the **slug**, the per-bug directory name under `.specify/bugs/`. Supply it with `slug=<name>`; if omitted, `/speckit-bug-assess` asks for one (or generates a unique one in automated mode). Slugs are normalized to lowercase kebab-case. If an assessment already exists for a slug, an interactive run asks before overwriting it, while an automated run refuses and picks a new unique slug instead.
 
 ```text
-/speckit.bug.assess -> /speckit.bug.fix -> /speckit.bug.test
+/speckit-bug-assess -> /speckit-bug-fix -> /speckit-bug-test
 ```
 
-## `/speckit.bug.assess`
+## `/speckit-bug-assess`
 
 Triages a bug report — pasted text (such as a stack trace) or a URL (such as a GitHub issue) — against the codebase: it judges whether the report is a real bug, locates the suspected code paths, and proposes a remediation. This command is **read-only**: it writes only `assessment.md` and never modifies source code.
 
 ```text
-/speckit.bug.assess "TypeError: cannot read properties of undefined (reading 'token') at /auth/callback"
+/speckit-bug-assess "TypeError: cannot read properties of undefined (reading 'token') at /auth/callback"
 ```
 
 ```text
-/speckit.bug.assess https://github.com/example/repo/issues/1234 slug=callback-token
+/speckit-bug-assess https://github.com/example/repo/issues/1234 slug=callback-token
 ```
 
 Output: `.specify/bugs/<slug>/assessment.md`.
 
-## `/speckit.bug.fix`
+## `/speckit-bug-fix`
 
 Applies the remediation described in the assessment and records exactly what changed. This is the **only** bug command that edits source code, and it stays within the files listed in the assessment unless new evidence requires expanding scope (logged under **Deviations from Assessment**).
 
 ```text
-/speckit.bug.fix slug=callback-token
+/speckit-bug-fix slug=callback-token
 ```
 
 Output: `.specify/bugs/<slug>/fix.md`.
 
-## `/speckit.bug.test`
+## `/speckit-bug-test`
 
 Validates the fix by re-running the reproduction and any added tests, then records the verification result — one of `verified`, `partial`, or `failed`. Like `assess`, it is **read-only** with respect to source code. Verdicts are never over-claimed: if the assessment listed a reproduction that wasn't actually exercised, the overall result is downgraded to `partial` rather than reported as `verified`.
 
 ```text
-/speckit.bug.test slug=callback-token
+/speckit-bug-test slug=callback-token
 ```
 
 Output: `.specify/bugs/<slug>/test.md`.
diff --git a/docs/reference/agentic-sdd.md b/docs/reference/agentic-sdd.md
index 7c8de58ff0..ce5235920d 100644
--- a/docs/reference/agentic-sdd.md
+++ b/docs/reference/agentic-sdd.md
@@ -2,7 +2,7 @@
 
 The `/speckit.*` slash commands drive the core Spec-Driven Development (SDD) process — an **agentic process** your coding agent runs step by step. For a guided, end-to-end run see the [Quick Start Guide](../quickstart.md); this page is the detailed reference for each command — including arguments, output, and how they interact. For the philosophy behind the process, see [What is SDD?](../concepts/sdd.md). For bug triage, see [Agentic Bug Fix](agentic-bugfix.md).
 
-The commands are designed to run in order, but only `/speckit.specify` is strictly required before `/speckit.plan`. The clarify, checklist, and analyze commands are quality gates you add for anything with meaningful ambiguity.
+The commands are designed to run in order, but only `/speckit-specify` is strictly required before `/speckit-plan`. The clarify, checklist, and analyze commands are quality gates you add for anything with meaningful ambiguity.
 
 For evaluating an idea before committing to a specification, see
 [Agentic Idea Assessment](agentic-assessment.md). Assessment is optional and
@@ -12,7 +12,7 @@ independent of the SDD process.
 > Commands are written in `/speckit.*` form throughout this page. GitHub Copilot's default skills mode uses `/speckit-*`; some other agents use `$speckit-*` (e.g. Codex, ZCode) or `/skill:speckit-*` (e.g. Kimi). See [Command invocation](integrations.md#command-invocation).
 
 ```text
-/speckit.constitution -> /speckit.specify -> /speckit.clarify -> /speckit.plan -> /speckit.checklist -> /speckit.tasks -> /speckit.analyze -> /speckit.implement -> /speckit.converge
+/speckit-constitution -> /speckit-specify -> /speckit-clarify -> /speckit-plan -> /speckit-checklist -> /speckit-tasks -> /speckit-analyze -> /speckit-implement -> /speckit-converge
 ```
 
 ## Command overview
@@ -24,68 +24,68 @@ skills by default.
 
 | Command | Agent skill | Purpose |
 | --- | --- | --- |
-| `/speckit.constitution` | `speckit-constitution` | Establish or update project principles |
-| `/speckit.specify` | `speckit-specify` | Define requirements and user stories |
-| `/speckit.plan` | `speckit-plan` | Create the technical implementation plan |
-| `/speckit.tasks` | `speckit-tasks` | Break the plan into actionable tasks |
-| `/speckit.implement` | `speckit-implement` | Execute the tasks |
-| `/speckit.converge` | `speckit-converge` | Assess implementation against the artifacts and append remaining work |
-| `/speckit.taskstoissues` | `speckit-taskstoissues` | Optionally convert tasks into GitHub issues |
-| `/speckit.clarify` | `speckit-clarify` | Resolve ambiguity before planning (optional quality gate; formerly `/quizme`) |
-| `/speckit.analyze` | `speckit-analyze` | Check artifact consistency after tasks and before implementation (optional quality gate) |
-| `/speckit.checklist` | `speckit-checklist` | Generate requirements-quality checklists (optional quality gate) |
-
-## `/speckit.constitution`
+| `/speckit-constitution` | `speckit-constitution` | Establish or update project principles |
+| `/speckit-specify` | `speckit-specify` | Define requirements and user stories |
+| `/speckit-plan` | `speckit-plan` | Create the technical implementation plan |
+| `/speckit-tasks` | `speckit-tasks` | Break the plan into actionable tasks |
+| `/speckit-implement` | `speckit-implement` | Execute the tasks |
+| `/speckit-converge` | `speckit-converge` | Assess implementation against the artifacts and append remaining work |
+| `/speckit-taskstoissues` | `speckit-taskstoissues` | Optionally convert tasks into GitHub issues |
+| `/speckit-clarify` | `speckit-clarify` | Resolve ambiguity before planning (optional quality gate; formerly `/quizme`) |
+| `/speckit-analyze` | `speckit-analyze` | Check artifact consistency after tasks and before implementation (optional quality gate) |
+| `/speckit-checklist` | `speckit-checklist` | Generate requirements-quality checklists (optional quality gate) |
+
+## `/speckit-constitution`
 
 Creates or updates the project **constitution** — the guiding principles that every later phase is evaluated against — and keeps dependent templates in sync. Run it once up front and update it whenever your principles change. Pass the principles as arguments.
 
 ```text
-/speckit.constitution This project follows a "Library-First" approach. All features must be implemented as standalone libraries first. We use TDD strictly. We prefer functional programming patterns.
+/speckit-constitution This project follows a "Library-First" approach. All features must be implemented as standalone libraries first. We use TDD strictly. We prefer functional programming patterns.
 ```
 
 For a more general starting point:
 
 ```text
-/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements.
+/speckit-constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements.
 ```
 
-## `/speckit.specify`
+## `/speckit-specify`
 
-Creates or updates the feature **specification** from a natural-language description. Focus on the **what** and **why** — the user-facing behavior and goals — not the tech stack, which belongs in `/speckit.plan`.
+Creates or updates the feature **specification** from a natural-language description. Focus on the **what** and **why** — the user-facing behavior and goals — not the tech stack, which belongs in `/speckit-plan`.
 
-This workflow may also maintain `checklists/requirements.md`, the built-in spec-quality checklist that `/speckit.specify` creates and `/speckit.clarify` re-evaluates. That lifecycle is separate from custom checklists generated by `/speckit.checklist`.
+This workflow may also maintain `checklists/requirements.md`, the built-in spec-quality checklist that `/speckit-specify` creates and `/speckit-clarify` re-evaluates. That lifecycle is separate from custom checklists generated by `/speckit-checklist`.
 
 ```text
-/speckit.specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page. Albums are never in other nested albums. Within each album, photos are previewed in a tile-like interface.
+/speckit-specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page. Albums are never in other nested albums. Within each album, photos are previewed in a tile-like interface.
 ```
 
-## `/speckit.clarify`
+## `/speckit-clarify`
 
 Asks up to five targeted questions about underspecified areas of the current spec and encodes your answers back into `spec.md`. Run it as many times as needed before planning, each time tackling a different area. Optionally pass a focus area as an argument.
 
 ```text
-/speckit.clarify Focus on the task card behavior: status changes, comment limits, and who can be assigned.
+/speckit-clarify Focus on the task card behavior: status changes, comment limits, and who can be assigned.
 ```
 
-Clarifying before planning keeps you from designing on top of ambiguity. If `/speckit.analyze` later surfaces requirement gaps, come back and run `/speckit.clarify` (or `/speckit.specify`) again.
+Clarifying before planning keeps you from designing on top of ambiguity. If `/speckit-analyze` later surfaces requirement gaps, come back and run `/speckit-clarify` (or `/speckit-specify`) again.
 
-When `checklists/requirements.md` exists, `/speckit.clarify` may update its evaluated state as part of tightening the spec. This exception applies only to the built-in requirements checklist, not to custom review checklists.
+When `checklists/requirements.md` exists, `/speckit-clarify` may update its evaluated state as part of tightening the spec. This exception applies only to the built-in requirements checklist, not to custom review checklists.
 
-## `/speckit.plan`
+## `/speckit-plan`
 
 Runs the planning process to generate design artifacts from the spec. This is where implementation detail belongs — provide your tech stack, architecture, and technical constraints as arguments.
 
 ```text
-/speckit.plan Use .NET Aspire with Postgres. The frontend is Blazor Server with drag-and-drop boards and real-time updates. Expose REST APIs for projects, tasks, and notifications.
+/speckit-plan Use .NET Aspire with Postgres. The frontend is Blazor Server with drag-and-drop boards and real-time updates. Expose REST APIs for projects, tasks, and notifications.
 ```
 
 For the photo-album example above:
 
 ```text
-/speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.
+/speckit-plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.
 ```
 
-## `/speckit.checklist`
+## `/speckit-checklist`
 
 Generates a quality checklist for the feature — think of it as **"unit tests for your requirements."** Rather than testing code, it checks whether the spec itself is complete, clear, unambiguous, and consistent (for example: "Are the drag-and-drop rules defined for every column?", "Is behavior specified for a deleted assigned user?").
 
@@ -94,77 +94,77 @@ Custom checklists generated by this command are reviewer-owned requirements-qual
 Run it with no arguments for a broad pass, or pass a focus area to target one aspect:
 
 ```text
-/speckit.checklist
+/speckit-checklist
 ```
 
 ```text
-/speckit.checklist Focus on the Kanban board interactions and comment permissions.
+/speckit-checklist Focus on the Kanban board interactions and comment permissions.
 ```
 
-Review the generated checklist. If it surfaces gaps, loop back to `/speckit.clarify` or `/speckit.specify` to tighten the spec before breaking the work down, then mark each custom checklist item `[x]` only after the requirements-quality criterion has been reviewed and satisfied.
+Review the generated checklist. If it surfaces gaps, loop back to `/speckit-clarify` or `/speckit-specify` to tighten the spec before breaking the work down, then mark each custom checklist item `[x]` only after the requirements-quality criterion has been reviewed and satisfied.
 
-## `/speckit.tasks`
+## `/speckit-tasks`
 
 Generates an actionable, dependency-ordered `tasks.md` from the design artifacts. Tasks are organized into phases: **Setup**, **Foundational** (blocking prerequisites), then **one phase per user story** in priority order, and a final **Polish** phase for cross-cutting concerns. Tests are generated within a user story's phase when requested rather than as a separate phase, and tasks are marked for parallel execution where possible.
 
 ```text
-/speckit.tasks
+/speckit-tasks
 ```
 
-## `/speckit.analyze`
+## `/speckit-analyze`
 
 Performs a **read-only** cross-artifact consistency and quality analysis across `spec.md`, `plan.md`, and `tasks.md`, reporting conflicts, gaps, and ambiguities (for example a task with no matching requirement, or a plan choice that contradicts the spec). It never edits files — it produces a report and can optionally suggest remediations for you to approve.
 
 ```text
-/speckit.analyze
+/speckit-analyze
 ```
 
-Run it before implementing, while the artifacts can still be adjusted cheaply. If it surfaces issues, **return to the earlier step that owns them** and fix them at the source — `/speckit.specify` or `/speckit.clarify` for requirement problems, `/speckit.plan` for design problems, `/speckit.tasks` to regenerate the task list — then re-run `/speckit.analyze` until it comes back clean. You can also run `/speckit.analyze` again after implementation as an extra review.
+Run it before implementing, while the artifacts can still be adjusted cheaply. If it surfaces issues, **return to the earlier step that owns them** and fix them at the source — `/speckit-specify` or `/speckit-clarify` for requirement problems, `/speckit-plan` for design problems, `/speckit-tasks` to regenerate the task list — then re-run `/speckit-analyze` until it comes back clean. You can also run `/speckit-analyze` again after implementation as an extra review.
 
-## `/speckit.implement`
+## `/speckit-implement`
 
 Executes the tasks in `tasks.md`, running each phase in dependency order and respecting parallel markers.
 
-Before executing tasks, it reads checklist checkbox state as a gate. Checklist markers are read-only for this command: `/speckit.implement` counts checked and unchecked items and asks before proceeding when any are unchecked, but it must not change checklist markers. For custom checklists, checked items mean reviewer approval of requirements quality, not completed implementation work.
+Before executing tasks, it reads checklist checkbox state as a gate. Checklist markers are read-only for this command: `/speckit-implement` counts checked and unchecked items and asks before proceeding when any are unchecked, but it must not change checklist markers. For custom checklists, checked items mean reviewer approval of requirements quality, not completed implementation work.
 
 For a small feature, run it once to build everything:
 
 ```text
-/speckit.implement
+/speckit-implement
 ```
 
 For a large feature, work in stages to avoid overwhelming the agent's context — scope each run with an argument, validate the result, then continue:
 
 ```text
-/speckit.implement Implement only the Setup and Foundational phases: project scaffolding and the project/task data model with basic CRUD. Stop before the user-story features.
+/speckit-implement Implement only the Setup and Foundational phases: project scaffolding and the project/task data model with basic CRUD. Stop before the user-story features.
 ```
 
 ```text
-/speckit.implement Now implement the Kanban board user story: drag-and-drop between columns.
+/speckit-implement Now implement the Kanban board user story: drag-and-drop between columns.
 ```
 
 Verify each stage works before moving to the next.
 
-## `/speckit.converge`
+## `/speckit-converge`
 
-Assesses the codebase against the feature's spec, plan, and tasks to confirm nothing was missed. It is **append-only**: it never edits or deletes code, and its only possible write is adding tasks to `tasks.md`. Run it only after `/speckit.implement` has run on the current `tasks.md`.
+Assesses the codebase against the feature's spec, plan, and tasks to confirm nothing was missed. It is **append-only**: it never edits or deletes code, and its only possible write is adding tasks to `tasks.md`. Run it only after `/speckit-implement` has run on the current `tasks.md`.
 
 ```text
-/speckit.converge
+/speckit-converge
 ```
 
 It first prints a severity-graded findings summary, then resolves to one of two outcomes:
 
 - **Converged** — no gaps found. `tasks.md` is left byte-for-byte unchanged and you'll see a clean result like `✅ Converged — the implementation satisfies the spec, plan, and tasks.` You're done; proceed to review or open a PR.
-- **Tasks appended** — gaps found. Converge appends them as new tasks under a Convergence section in `tasks.md` and tells you how many. Run `/speckit.implement` again to complete them, then `/speckit.converge` once more. Each pass finds fewer items; repeat until it reports converged.
+- **Tasks appended** — gaps found. Converge appends them as new tasks under a Convergence section in `tasks.md` and tells you how many. Run `/speckit-implement` again to complete them, then `/speckit-converge` once more. Each pass finds fewer items; repeat until it reports converged.
 
-## `/speckit.taskstoissues`
+## `/speckit-taskstoissues`
 
 Optionally converts an existing `tasks.md` into actionable GitHub issues. Run it
 after generating tasks when you want to track execution in GitHub:
 
 ```text
-/speckit.taskstoissues
+/speckit-taskstoissues
 ```
 
 This command requires a GitHub `origin` remote and access to the GitHub MCP tools
diff --git a/docs/reference/core.md b/docs/reference/core.md
index b70aebe236..8e2b3b8c58 100644
--- a/docs/reference/core.md
+++ b/docs/reference/core.md
@@ -51,9 +51,9 @@ specify init my-project --integration copilot --preset compliance
 | Variable          | Description                                                              |
 | ----------------- | ------------------------------------------------------------------------ |
 | `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_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` | 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` | 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. |
 
 > **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.
 
diff --git a/docs/upgrade.md b/docs/upgrade.md
index c3c8330591..fb854e05a4 100644
--- a/docs/upgrade.md
+++ b/docs/upgrade.md
@@ -355,7 +355,7 @@ export SPECIFY_FEATURE_DIRECTORY="specs/001-my-feature"
 $env:SPECIFY_FEATURE_DIRECTORY = "specs/001-my-feature"
 ```
 
-Alternatively, run the `/speckit.specify` command which creates `.specify/feature.json` automatically.
+Alternatively, run the `/speckit-specify` command which creates `.specify/feature.json` automatically.
 
 ---
 
@@ -498,7 +498,7 @@ The `specify` CLI tool is used for:
 - **Fallback recovery:** `specify init --here --force` when integration metadata is missing or the manifest-aware path cannot be used
 - **Diagnostics:** `specify check` to verify tool installation
 
-Once you've run `specify init`, the slash commands (like `/speckit.specify`, `/speckit.plan`, etc.) are **permanently installed** in your project's agent folder (`.claude/`, `.github/prompts/`, `.pi/prompts/`, `.omp/commands/`, etc.). Your AI coding agent reads these command files directly—no need to run `specify` again.
+Once you've run `specify init`, the slash commands (like `/speckit-specify`, `/speckit-plan`, etc.) are **permanently installed** in your project's agent folder (`.claude/`, `.github/prompts/`, `.pi/prompts/`, `.omp/commands/`, etc.). Your AI coding agent reads these command files directly—no need to run `specify` again.
 
 **If your agent isn't recognizing slash commands:**
 
@@ -544,7 +544,7 @@ Spec Kit follows semantic versioning for major releases. The CLI and project fil
 
 After upgrading:
 
-- **Test new slash commands:** Run `/speckit.constitution` or another command to verify everything works
+- **Test new slash commands:** Run `/speckit-constitution` or another command to verify everything works
 - **Review release notes:** Check [GitHub Releases](https://github.com/github/spec-kit/releases) for new features and breaking changes
 - **Update workflows:** If new commands were added, update your team's development workflows
 - **Check documentation:** Visit [github.io/spec-kit](https://github.github.io/spec-kit/) for updated guides