Skip to content

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

Description

@echarrod

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:

Layer Purpose
Preset Overrides speckit.taskstoissues to target Jira
Extension (existing) Provides supplementary Jira-specific commands (discover-fields, sync-status)

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?

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions