improvement: optionally create feature branch in /specify

[jxstanford]

It would be useful to be able to use /specify without creating a new branch for the feature. This would accommodate projects that have lots of legacy branches that they might want to spec to complete, or have existing processes/standards that govern branch creation. There's a slight impedence mismatch, but you could use /specify --here {instructions} or /specify-here {instructions} to be consistent with the CLI method of inheriting existing state.

[outp1]

Having a large number of command files that are not essential to the core SDD workflow could feel like overkill for some project repositories. Still, I don’t think that means we shouldn’t support such cases. It seems more like we’ve hit the limitations of cli-kit as an extractor of scripts, templates, and instructions for generating project files with LLMs.

My initial suggestion would be to introduce a catalog of additional “static” files for more specific use cases. For example, we could expand the init command of spec-kit with an option such as --add-ons=(list of add-on groups). These add-ons could serve as a testing ground for other initiatives (examples: #50, #153) before being merged, or remain available for explicit installation.

This is just an idea that came to me while reading @jxstanford’s issue. I’ll start a suggestion topic to discuss it further

[eriksenonline]

Would it be possible to not create branches but assume the working branch should already be checked out. We use gitlab and create MR's and branches, then checkout and work on this branch. Mayby this is not the best flow I do not know but it is how we do it :)

Mayby do this with a env file or somthing?

[ReddragonLR]

I also prefer the idea of optionally creating a feature branch.

I make use of the feat/ prefix in feature branch-names. I do this because I have specific GitHub actions that run on feature branches. As such, erroring out when the CURRENT_BRANCH does not match the regex ^[0-9]{3}- ]] is a little restrictive. I have made a change locally on my project to allow me to use the feat/ prefix by making the following changes:

# Extract feature name from branch (removes feat/ prefix if present)
extract_feature_name() {
    local branch="$1"
    if [[ "$branch" =~ ^feat/(.+)$ ]]; then
        echo "${BASH_REMATCH[1]}"
    else
        echo "$branch"
    fi
}

check_feature_branch() {
    local branch="$1"
    local has_git_repo="$2"

    # For non-git repos, we can't enforce branch naming but still provide output
    if [[ "$has_git_repo" != "true" ]]; then
        echo "[specify] Warning: Git repository not detected; skipped branch validation" >&2
        return 0
    fi

    # Extract feature name (removes feat/ if present) for validation
    local feature_name=$(extract_feature_name "$branch")

    if [[ ! "$feature_name" =~ ^[0-9]{3}- ]]; then
        echo "ERROR: Not on a feature branch. Current branch: $branch" >&2
        echo "Feature branches should be named like: 001-feature-name or feat/001-feature-name" >&2
        return 1
    fi

    return 0
}

get_feature_dir() {
    local repo_root="$1"
    local branch="$2"
    local feature_name=$(extract_feature_name "$branch")
    echo "$repo_root/specs/$feature_name"
}

[sephib]

+1 on this idea
i have a similar issue since some of our branches are made from Jira workflows that create branches

[bobbui]

+1 on this, this is especially useful for continuous vibe coding on local machine

[mnriem]

Superseded by #1680 (use existing branch, without auto branch creation), with #1921/#2047 covering configurable branching; worktree concerns are handled by the now-optional git extension and closed #61/#1476