Consider Jira issue creation as a preset rather than extension #2223

Summary

The current community Jira integration (spec-kit-jira) is implemented as an extension, which means it provides a parallel command (speckit.jira.specstoissues) rather than replacing the core speckit.taskstoissues. This creates friction for Jira-using teams since the natural workflow path remains hardcoded to GitHub Issues.

Problem

The core speckit.taskstoissues command:

• Checks that the git remote is a GitHub URL
• Explicitly refuses to proceed for non-GitHub remotes
• Uses GitHub MCP tools to create issues

For Jira teams, this means:

1. The natural /speckit.taskstoissues command is unusable
2. Users must remember to use /speckit.jira.specstoissues instead
3. The extension cannot alias itself as speckit.taskstoissues due to extension naming rules requiring the speckit.{ext-id}.{command} prefix (spec-kit-jira#2)

Proposal

Issue tracking provider selection (GitHub Issues vs Jira vs Linear etc.) is a core workflow decision, not an additive feature. The preset system was designed exactly for this — overriding core commands with alternate implementations.

A Jira preset could override speckit.taskstoissues so that /speckit.taskstoissues creates Jira epics/stories/tasks instead of GitHub issues. This keeps the natural workflow intact.

The ideal architecture would be:

This pattern would also apply to other issue trackers (Linear, Azure DevOps, etc.) — each would provide a preset to swap the core issue creation path.

Questions

• Is this the intended use of presets, or is there a different recommended approach for swapping issue tracking providers?
• Should the preset catalog include "issue tracker" presets as a category?
• Would it make sense for the existing spec-kit-jira extension to also ship a preset component, or should these remain separate?