Release CLI: --issue-pattern flag to extract issue IDs from custom subject formats (e.g. Conventional Commits)

[olsavmic]

Problem

Issue identifiers are extracted from a commit subject only when the identifier leads the subject. The three built-in subject conventions in src/extractors.ts (COMMON_SUBJECT_PATTERNS) are all start-anchored:

• [ENG-123] My change
• (ENG-123) My change
• ENG-123: My change

Teams that follow Conventional Commits put the identifier after the type and optional scope, so none of these match and the issue is never linked to the release:

feat(routing)[ENG-123]: add stop reordering
fix[ENG-123]: handle empty payload
chore(deps)[ENG-7]: bump

(fix[ENG-123] also slips past the fix magic-word path, since that path requires whitespace/colon after the keyword, not [.)

--include-subjects doesn't help here — it's a filter (decides which commits to scan), not an extractor (it can't tell the CLI where the identifier lives within the subject). There's currently no way to teach the scanner a custom subject convention.

Proposal

Add a --issue-pattern=<regex> flag for sync. The user supplies a regex whose first capture group is the team key and second capture group is the issue number:

# Conventional Commits: type, optional (scope), optional !, then [TEAM-NUMBER]
linear-release sync --issue-pattern="\w+(?:\([^)]*\))?!?\[(\w+)-(\d+)\]"

Behavior:

• Matched against the commit subject (first line only), consistent with --include-subjects and the built-in subject patterns.
• Scanned globally, so a subject may carry more than one identifier.
• Case-insensitive; team key upper-cased and leading zeros stripped (eng-0045 → ENG-45); numbers written with a leading zero are rejected, matching parseMatch.
• Additive — merged with the existing branch-name / magic-word / built-in-subject detection and de-duplicated, not a replacement.
• Validated at parse time: the regex must compile and have at least two capturing groups (helpful error otherwise).

This keeps the default detection untouched while giving teams an escape hatch for any subject convention the built-ins don't recognize.

Happy to send a PR (already drafted, with unit tests + README docs).

[linear-code]

LIN-74725

[olsavmic]

Reopening — there's a sharper framing than "support arbitrary conventions".

Our commit/PR titles look like:

feat(vehicle)[LMC-123]: some commit reason

That's just Conventional Commits with the Linear ID in brackets after the type(scope). Linear itself already recognizes this — it auto-links the PR to LMC-123 (the issue shows the PR under its Links), so the format is unambiguously valid as far as Linear's own detection goes.

But linear-release does not match it. The built-in subject patterns are start-anchored — [LMC-123] …, (LMC-123) …, LMC-123: … — so an identifier sitting after feat(vehicle) is never extracted, and the issue is dropped from the release even though Linear has already linked the very same PR to that issue.

So this isn't a request for an exotic convention — it's an inconsistency between Linear's own PR auto-linking and what the release CLI scans. At minimum the CLI should recognize the same type(scope)[ID]: shape Linear already does.

(#71 previously proposed a general --issue-id-pattern regex flag for exactly this and was closed unmerged.)