What happened
A feature description written entirely in a non-Latin script produces a branch and directory with no name at all — just the number and a trailing dash. Every such feature looks identical apart from its number.
specify init demo --integration claude
./.specify/scripts/powershell/create-new-feature.ps1 -Json "给倒推引擎加正推能力"
# {"BRANCH_NAME":"001-", ... "specs\\001-\\spec.md"}
./.specify/scripts/powershell/create-new-feature.ps1 -Json "客户邮件审核队列"
# {"BRANCH_NAME":"004-", ... "specs\\004-\\spec.md"}
Resulting tree — two unrelated features, indistinguishable:
specs/
├── 001-/
├── 004-/
└── 005-mail-review-queue/ # same description, but with -ShortName
For comparison, on the same install:
| Description |
BRANCH_NAME |
给倒推引擎加正推能力 |
001- |
add forward scheduling engine |
002-forward-scheduling-engine |
forward 正推 engine |
003-forward-engine (Latin words kept, rest dropped) |
Why this is not the already-known crash
Get-BranchName in create-new-feature.ps1 already carries a comment describing this path — a previous fix stopped it throwing ArgumentNullException and made it return an empty suffix instead, matching the bash and Python twins. That fix is correct as far as it goes: the script no longer dies.
But the outcome it settles on is a directory name that carries no information. The empty suffix is a reasonable internal result; it just isn't a usable name. For a team working in Chinese, Japanese, Korean, Arabic, Hebrew, Thai, Greek, or Cyrillic, this is the default path, not an edge case — every feature they create lands in NNN-.
The root cause is the character class, in two places:
# line 89
$Name.ToLower() -replace '[^a-z0-9]', '-' ...
# line 136
$Description.ToLower() -replace '[^a-z0-9\s]', ' '
Both drop every non-ASCII character, so a CJK description reduces to the empty string before stop-word filtering ever runs.
Suggested directions
Listed roughly by cost; any one of them removes the nameless directory.
- Warn and point at the escape hatch.
-ShortName already works (005-mail-review-queue above). When the computed suffix is empty, print a line saying the description produced no usable branch name and that -ShortName <name> sets one. Cheapest fix, and it turns a silent surprise into a choice.
- Fall back to something stable instead of nothing. A short hash or timestamp of the description —
001-f3a9c2, 001-20260914 — is still opaque, but at least distinct per feature.
- Widen the character class. Keep Unicode letters and digits (
\p{L}\p{N}) and percent-encode or transliterate what git cannot take. Git branch names do accept UTF-8, so 001-客户邮件审核队列 is a legal ref; whether it is desirable is a separate call, and tooling downstream may not all agree.
(1) alone would have saved the confusion here. (3) is the real fix but needs a decision about non-ASCII refs that is yours to make, not mine.
Environment
- specify-cli
1.0.7.dev0 (git d848fb4), installed via uv tool install
- Windows 11, PowerShell 5.1, Python 3.13.7, git 2.49.0.windows.1
--script auto-selected powershell
Not PowerShell-specific — reproduced on both script backends:
specify init demo-sh --integration claude --script sh
bash .specify/scripts/bash/create-new-feature.sh --json "给倒推引擎加正推能力"
# {"BRANCH_NAME":"001-", ... "specs/001-/spec.md"}
What happened
A feature description written entirely in a non-Latin script produces a branch and directory with no name at all — just the number and a trailing dash. Every such feature looks identical apart from its number.
Resulting tree — two unrelated features, indistinguishable:
For comparison, on the same install:
给倒推引擎加正推能力001-add forward scheduling engine002-forward-scheduling-engineforward 正推 engine003-forward-engine(Latin words kept, rest dropped)Why this is not the already-known crash
Get-BranchNameincreate-new-feature.ps1already carries a comment describing this path — a previous fix stopped it throwingArgumentNullExceptionand made it return an empty suffix instead, matching the bash and Python twins. That fix is correct as far as it goes: the script no longer dies.But the outcome it settles on is a directory name that carries no information. The empty suffix is a reasonable internal result; it just isn't a usable name. For a team working in Chinese, Japanese, Korean, Arabic, Hebrew, Thai, Greek, or Cyrillic, this is the default path, not an edge case — every feature they create lands in
NNN-.The root cause is the character class, in two places:
Both drop every non-ASCII character, so a CJK description reduces to the empty string before stop-word filtering ever runs.
Suggested directions
Listed roughly by cost; any one of them removes the nameless directory.
-ShortNamealready works (005-mail-review-queueabove). When the computed suffix is empty, print a line saying the description produced no usable branch name and that-ShortName <name>sets one. Cheapest fix, and it turns a silent surprise into a choice.001-f3a9c2,001-20260914— is still opaque, but at least distinct per feature.\p{L}\p{N}) and percent-encode or transliterate what git cannot take. Git branch names do accept UTF-8, so001-客户邮件审核队列is a legal ref; whether it is desirable is a separate call, and tooling downstream may not all agree.(1) alone would have saved the confusion here. (3) is the real fix but needs a decision about non-ASCII refs that is yours to make, not mine.
Environment
1.0.7.dev0(gitd848fb4), installed viauv tool install--scriptauto-selectedpowershellNot PowerShell-specific — reproduced on both script backends: