bug: automatic branch naming repeats numbering prefix such as 001-second-branch after 001-first-branch

[cswaas]

I'm using the PR-986 version of Spec Kit with VS Code Insideres based on Dan's recent Youtube video.
With the second speckit.specify command the new branch gets again a 001- prefix to its name. Should it not be 002- ?

[wysiecki]

happens with claude code too

[bing5tui3]

same issue, and this bug imported recently, it was good before

[george-mcintyre]

Its because the lines 90... in .specify/scripts/bash/create-new-feature.sh includes ${short_name} in the regex that seeks to list existing features, so it never matches anything as no prior feature has the same name, and so it thinks its the first time.

    # Find all branches matching the pattern using git ls-remote (more reliable)
    local remote_branches=$(git ls-remote --heads origin 2>/dev/null | grep -E "refs/heads/[0-9]+-${short_name}$" | sed 's/.*\/\([0-9]*\)-.*/\1/' | sort -n)
    
    # Also check local branches
    local local_branches=$(git branch 2>/dev/null | grep -E "^[* ]*[0-9]+-${short_name}$" | sed 's/^[* ]*//' | sed 's/-.*//' | sort -n)
    
    # Check specs directory as well
    local spec_dirs=""
    if [ -d "$SPECS_DIR" ]; then
        spec_dirs=$(find "$SPECS_DIR" -maxdepth 1 -type d -name "[0-9]*-${short_name}" 2>/dev/null | xargs -n1 basename 2>/dev/null | sed 's/-.*//' | sort -n)
    fi

Unfortunately when I fixed that locally a bunch of other problems appeared so the best workaround I have is to wait till its done then simply ask it to change the spec name and branch and make sure any remote branch names are also changed. It works well and then everything is ok from then onwards

Prompt:

/speckit.specify.md Please rename the feature and the branch from 001-feature to 002-feature.   Rename feature folders and update all specifications you've created to reflect the new name. Make sure that any remote branches that may have been created are also renamed. 

[mosherbrian]

I ran into this too. It seems like a pretty fundamental part of the functionality. Why isn't everyone seeing this same blocker? Shouldn't basic happy path testing have caught this before release?

I was able to patch it locally by modifying the regex in create-new-feature.sh to match only the starting three digit numbering prefix. The same basic change is needed as well in speckit.specify.md in the second stage of the prompt:

`2. Check for existing branches before creating new one:

a. First, fetch all remote branches to ensure we have the latest information:
bash git fetch --all --prune

b. Find the highest feature number across all sources:
- Remote branches: git ls-remote --heads origin | grep -E 'refs/heads/[0-9]+-'
- Local branches: git branch | grep -E '^[* ]*[0-9]+-'
- Specs directories: Check for directories matching specs/[0-9]+-
`

[tianhaoz95]

Any updates on this? this is nearly unusable since even after renaming it, it will still re-create it.

[mosherbrian]

You can try my double patch removing the short name in both the script and the prompt. That will get you working again, although it feels a little hacky.

[Douda]

Hi all,

Noticed the same issue with Claude Code.
Found a quick way to remediate the wrong numbered branch which seem to work (requires investigation though as I'(m not 100% confident this is the root cause)

When Claude detects correctly the number, it always uses the 3 digits number (023 in this example) and it fails to create the corret branch

● Perfect! The next feature number is 023. Now let me run the create-new-feature script:

● Bash(.specify/scripts/bash/create-new-feature.sh --json --number 023 --short-name "cli-async-audit" "cli tools
      async. When prior specs switched the project to full D…)
  ⎿  {                                                                                 
       "BRANCH_NAME": "019-cli-async-audit",
       "SPEC_FILE": "/home/user01/Projects/MyProject/specs/019-cli-async-audit/spec.md",
     … +3 lines (ctrl+o to expand)

When instructed to drop the first "0" it works :

when you run the .sh tool, use --number 23 and not 023 

● You're right! Let me run the script with the correct number format:

● Bash(.specify/scripts/bash/create-new-feature.sh --json --number 23 --short-name "cli-async-audit" "cli tools
      async. When prior specs switched the project to full DB…)
  ⎿  {                                                                                 
       "BRANCH_NAME": "023-cli-async-audit",
       "SPEC_FILE": "/home/user01/Projects/MyProject/specs/023-cli-async-audit/spec.md",
     … +3 lines (ctrl+o to expand)

[chriso0710]

Happens to me too with Claude code and Spec Kit CLI Version 0.0.22 Template Version 0.0.89 Released 2025-12-02

Surprisingly Claude detects the mistake during the plan and corrects it automatically:

I see the issue - there's already a 001-slug-override-field directory. When I created the new feature, I should have checked more carefully and used
  number 003 instead. Let me check the branch numbering logic again:

⏺ Bash(git branch -a | grep -E '[0-9]+-icon-reaction-timeline')
  ⎿  * 001-icon-reaction-timeline

⏺ The issue is that I should have used feature number 003 (not 001) since there's already a 001-slug-override-field. Let me fix this by renaming the
  directory and branch:
...

[chriso0710]

I asked Claude to analyse the .specify/scripts dir to find the numbering bug. This is what he came up with:

Root Cause Analysis

I've identified the bug in the branch numbering logic. The issue is in the check_existing_branches() function in
.specify/scripts/bash/create-new-feature.sh:129-159.

The Problem

The script has two different strategies for finding the next available number:

1. Global strategy: get_highest_from_specs() (lines 83-101) and get_highest_from_branches() (lines 103-127) find the highest number across ALL
   features
2. Name-specific strategy: check_existing_branches() (lines 129-159) only searches for features with the SAME name

Currently, the name-specific strategy is being used (line 250), which causes the numbering collision.

Reproduction Steps

Given existing specs:

• 001-slug-override-field
• 002-i18n-browser-detection
• 003-icon-reaction-timeline

When creating a new feature with a different name (e.g., "user-authentication"):

1. check_existing_branches("user-authentication", ...) is called
2. Line 138: searches for pattern refs/heads/[0-9]+-user-authentication$
3. Finds nothing (no features with that specific name exist yet)
4. max_num remains 0
5. Returns 1 → creates branch 001-user-authentication
6. Conflict! 001-slug-override-field already exists

The Fix

The check_existing_branches() function should find the highest number across ALL features, regardless of name. The script already has the correct
functions for this:

• get_highest_from_specs(): finds highest number in specs/ directory
• get_highest_from_branches(): finds highest number in git branches

These functions correctly search for ^[0-9]+ or ^[0-9]{3}- patterns without filtering by name.

Suggested Solution

Replace the name-specific logic in check_existing_branches() with a global search, or directly use the combination of get_highest_from_branches() and
get_highest_from_specs() instead of calling check_existing_branches().

The name-specific search only makes sense if you want to detect duplicate feature names (e.g., 001-auth, 002-auth), but not for global numbering
across all features.

Code Reference

The bug is triggered here (lines 246-256):

if [ -z "$BRANCH_NUMBER" ]; then
    if [ "$HAS_GIT" = true ]; then
        # This uses name-specific search - BUG!
        BRANCH_NUMBER=$(check_existing_branches "$BRANCH_SUFFIX" "$SPECS_DIR")
    else
        # This correctly uses global search
        HIGHEST=$(get_highest_from_specs "$SPECS_DIR")
        BRANCH_NUMBER=$((HIGHEST + 1))
    fi
fi

The non-git fallback path (lines 253-254) actually works correctly because it uses the global get_highest_from_specs() function.

[mosherbrian]

I see that PR 1237 was just merged. I'm curious if that also addresses this issue.

[pizzooid]

I see that PR 1237 was just merged. I'm curious if that also addresses this issue.

For me the other pr doesn't seem to suffice.

[eugman]

I see that PR 1237 was just merged. I'm curious if that also addresses this issue.

For me the other pr doesn't seem to suffice.

Claude advised this, so take it with a huge grain of salt, but it looks like .claude\commands\speckit.specify.md needs updated to take advantage of the fixes in the PR.

Changing the prompt solved the issue for me, although Claude code fumbled with the Powershell format multiple times so I'm sure it needs iterated on.