Customize Feature Number to include External Reference

[termleech]

In the workflow for my company we use JIRA and include the ticket number in our branches. The workflow I am testing uses the atlassian MCP and use a prompt similar to /specify JIRA ticket <URL>. Instead of using next for the feature number I would prefer instead to just use the JIRA ticket numbers. Opening this up for discussion.

[amondnet]

@termleech
Using the hook system might partially resolve the issue.

#343
#345

[t-sakoda]

We're running into a related issue on our project. We use GitHub issue numbers as branch prefixes (e.g., 1234-user-authentication) via --number, and the prepare-feature-num hook (#345) could also help with the number generation side.

However, even when a custom number is successfully assigned, common.sh hardcodes 3-digit matching throughout, which breaks other commands (plan, tasks, implement, etc.) for branches with 4+ digit prefixes.

Specifically, these patterns in common.sh (v0.4.2) use {3} instead of +:

Function	Pattern	Line
get_highest_from_specs()	'^[0-9]\{3\}-'	~94
get_highest_from_branches()	'^[0-9]\{3\}-' (×2)	~113, ~115
get_current_branch()	^([0-9]{3})-	~74
check_feature_branch()	^[0-9]{3}-	~103
find_feature_dir_by_prefix()	^([0-9]{3})-	~120

Additionally, create-new-feature.sh zero-pads with printf "%03d" (line ~282), which is fine for 4+ digits but signals an assumption of 3-digit numbers.

We've been maintaining local patches ({3} → +) for months and it works well. A minimal fix would be changing these patterns to support variable-length numeric prefixes, which would unblock both --number with external IDs (JIRA, GitHub issues, etc.) and the prepare-feature-num hook for real-world use cases.

Happy to submit a PR if this direction sounds reasonable.

[mnriem]

Are you hitting this with the latest version? If so yes please submit a PR