[Feature]: Remove taskstoissues from the core command set

まず、issue で言及されているコアコマンドテンプレート、コマンドインベントリ、統合の足場、生成されるコマンドに関する期待事項から始めます。次に、エージェント固有の宣言と、統合・プリセット・拡張機能のテストを調べ、taskstoissues が常にインストールされていることを前提としていないか確認します。新規プロジェクトにコアコマンドが存在せず、github-issues 拡張機能が正規のものとして維持され、互換性とフックが安全に処理され、移行ドキュメントが更新されていれば完了です。

Problem Statement

After the bundled GitHub Issues extension is available and the core /speckit.taskstoissues command has completed a deprecation period, retaining both implementations leaves GitHub-specific project-management behavior in the core SDD command set and creates duplicate maintenance surfaces.

The final migration stage should make the extension the sole owner of GitHub issue creation.

Proposed Solution

After #4421 and #4422 have shipped in earlier minor releases, remove taskstoissues from the core command set.

The removal should cover all core-owned surfaces, including:

• The core command template.
• Core command inventories, ordering, and descriptions.
• Integration scaffolding and generated core command expectations.
• Agent-specific argument descriptions and tool declarations.
• Tests that assume taskstoissues is always installed as a core command.
• README, installation, integration, and upgrade documentation.

The bundled github-issues extension should become the sole implementation and continue to provide speckit.github-issues.taskstoissues.

Once the core namespace is free, add speckit.taskstoissues as a deprecated compatibility alias in the extension if the extension command and alias validation rules support it safely. The namespaced command remains canonical. Projects without the extension should no longer receive any tasks-to-issues command.

Document the breaking change prominently and provide an agent-consumable migration recipe:

specify extension add github-issues
specify integration upgrade <integration>

The exact refresh command should be verified against the supported upgrade flow before publication.

Alternatives Considered

• Retain the deprecated core command indefinitely: Leaves provider-specific functionality and duplicate maintenance in core.
• Auto-install the extension for everyone: Preserves behavior but defeats the goal of making issue tracking opt-in.
• Remove the core command without a compatibility alias: Simpler, but unnecessarily disrupts users who have installed the replacement extension and still invoke the legacy name.

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

All agents

Use Cases

1. New projects receive only the core SDD workflow unless they explicitly opt into GitHub issue tracking.
2. GitHub issue functionality can evolve and release independently as an extension.
3. Other issue-tracker providers can offer parallel extensions without replacing a core command.

Acceptance Criteria

• This issue is implemented only after #4421 and #4422 have shipped in earlier minor releases.
• taskstoissues is removed from the core command templates and inventories.
• Fresh projects do not receive a tasks-to-issues command unless github-issues is installed.
• The extension remains installable and provides the canonical speckit.github-issues.taskstoissues command.
• A deprecated speckit.taskstoissues extension alias is provided if it can be registered safely after the core command is removed.
• Extension hooks using before_taskstoissues and after_taskstoissues continue to function when the extension command runs.
• Integration, preset, and extension tests are updated for the new opt-in behavior.
• Upgrade documentation clearly identifies the removal as breaking and provides migration commands.
• Related work, including #4370 and #2223, references the extension rather than the removed core command.
• The removal is included in a later minor release.

Additional Context

This is stage 3 of the migration:

1. #4421 adds the bundled GitHub Issues extension.
2. #4422 deprecates the core command after the replacement ships.
3. This issue removes the command from core after the deprecation window.

Spec Kit's current release guidance treats the version as a release identifier rather than a promise that breaking changes require a new major version. The removal may therefore ship in a minor release, provided it is clearly identified and documented as breaking.

Related discussion: #4370, especially https://github.com/github/spec-kit/issues/4370#issuecomment-5525946904.