Skip to content

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

@echarrod

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions