fix(scripts): keep PowerShell branch-name acronym match case-sensitive (parity with bash)

[jawwad-ali]

Description

Get-BranchName (and its bash twin generate_branch_name) drop words shorter than 3 characters when deriving the feature branch / spec-directory name from a description — unless the word appears as an UPPERCASE acronym in the original (e.g. keep GO in "Use GO now", drop go in "Add go support").

The bash scripts check the acronym case-sensitively:

# scripts/bash/create-new-feature.sh
elif echo "$description" | grep -q "\b${word^^}\b"; then        # keep only if UPPERCASE form present
# extensions/git/scripts/bash/create-new-feature-branch.sh
elif echo "$description" | grep -qw -- "${word^^}"; then

The PowerShell twins used -match, which is case-insensitive by default:

} elseif ($Description -match "\b$($word.ToUpper())\b") {   # matches the lowercased word too!

So PowerShell kept every short word regardless of case — contradicting its own adjacent comment ("Keep short words if they appear as uppercase in original (likely acronyms)") and diverging from the bash twin. The result: the same description yields different branch and specs/ directory names depending on which shell ran, desyncing specs/, feature.json, and git branches across a mixed-OS team. create-new-feature is what /speckit.specify runs for every project, and create-new-feature-branch backs /speckit.git.feature.

Fix

Use the case-sensitive -cmatch (the word is already .ToUpper()-ed) so a short word is kept only for a genuine uppercase acronym — matching bash. Two one-token changes:

• scripts/powershell/create-new-feature.ps1
• extensions/git/scripts/powershell/create-new-feature-branch.ps1

Purely a correctness fix; no flags, output keys, or other behavior change.

Evidence (verified locally, both shells)

Description	bash (correct)	PowerShell before (-match)	PowerShell after (-cmatch)
Add go support	001-support	001-go-support ❌	001-support ✅
my db is slow	001-slow	001-db-slow ❌	001-slow ✅
Use GO now (real acronym)	001-use-go-now	001-use-go-now	001-use-go-now ✅

Isolation check: 'Add go support' -match '\bGO\b' → True (bug); 'Add go support' -cmatch '\bGO\b' → False (fixed); 'Use GO now' -cmatch '\bGO\b' → True (acronym preserved).

Testing

• Tested locally with uv run specify --help (exit 0)
• Ran existing tests with uv sync && uv run pytest
• Verified both scripts end-to-end (bash directly; the fixed .ps1 via PowerShell) produce identical branch names

Added regression tests (assert a lowercase short word is dropped and an uppercase acronym is kept), covering both fixed scripts on both shells:

• tests/test_timestamp_branches.py::TestSequentialBranch (core, bash) and ::TestSequentialBranchPowerShell (core, pwsh)
• tests/extensions/git/test_git_extension.py::TestCreateFeatureBash and ::TestCreateFeaturePowerShell (git extension)

uvx ruff check src/ <changed tests> clean. The new bash/PowerShell tests run on the CI matrix (ubuntu bash, windows pwsh); on my local host they skip (no pwsh/detected bash), so I confirmed the behavior by running the scripts directly (table above) — the PowerShell tests fail against the pre-fix -match and pass with -cmatch.

Out of scope

While here I noticed the git-extension PowerShell script also emits a HAS_GIT key in its JSON/text output that the bash twin doesn't — a separate, lower-impact output-parity nit. Happy to follow up in its own PR to keep this one focused.

AI Disclosure

• I did not use AI assistance for this contribution
• I did use AI assistance (describe below)

Found and fixed with Claude Code (Claude Opus 4.8) under my direction. AI located the bash/PowerShell divergence, made the -cmatch change, and wrote the regression tests; I reproduced the differing branch names on both shells, confirmed the fix produces parity, and reviewed the diff before submitting. I'll disclose if any review responses are AI-assisted as well.