Skip to content

feat: provider-aware issue ID formatting#602

Open
acreeger wants to merge 10 commits intomainfrom
epic/595-provider-aware-issue-id-formatting
Open

feat: provider-aware issue ID formatting#602
acreeger wants to merge 10 commits intomainfrom
epic/595-provider-aware-issue-id-formatting

Conversation

@acreeger
Copy link
Collaborator

Summary

  • Add formatIssueId method to IssueTracker interface and static utility on IssueTrackerFactory so issue IDs are formatted correctly per provider (GitHub: #123, Jira: QLH-4404, Linear: ENG-123)
  • Migrate all hardcoded # prefixes in core commands (start, finish, enhance, cleanup, commit, plan) and lib files (PRManager, LoomManager, LoomLauncher, IssueEnhancementService) to use formatIssueId
  • Add ISSUE_PREFIX template variable to Handlebars templates so agent prompts render issue IDs correctly for all providers

Test plan

  • pnpm build passes
  • All 3838 tests pass (0 failures)
  • Manual: Configure GitHub provider → output shows Issue #123
  • Manual: Configure Jira provider → output shows Issue QLH-4404 (no #)
  • Manual: Configure Linear provider → output shows Issue ENG-123 (no #)

Closes #595, closes #596, closes #598, closes #599, closes #600, closes #601

@acreeger
Copy link
Collaborator Author

@NoahCardoza I've implemented #595 here - I'll take do a deeper review tomorrow but feel free to take a look too (if you want, no obligation!)

* @param identifier - The issue identifier (number or string)
* @returns Formatted issue ID string
*/
static formatIssueId(providerType: IssueTrackerProviderType, identifier: string | number): string {
Copy link
Contributor

@NoahCardoza NoahCardoza Feb 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My original plan was to have each issue tracker service implement it's own static formatIssueId method, and then use this factory method to route between them in areas where we didn't need a whole issue tracker service instance.

That way there is a single source of truth and implementing a new service doesn't require knowing this has to be updated too. We could implement a typescript guard to ensure an error is thrown if a new provider is added and didn't update this switch-case.

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

Labels

None yet

Projects

Status: No status

2 participants

Comments