Skip to content

Bug: spec-kit uses parent git repo instead of .specify directory as root #1932

Description

@mbachorik

Description

When spec-kit is initialized in a subdirectory that doesn't have its own .git, but a parent directory does, spec-kit incorrectly uses the parent's git repository root instead of the directory containing .specify.

Steps to Reproduce

  1. Have a parent directory with git initialized: /work/ (contains .git)
  2. Create a subdirectory: /work/my-project/
  3. Initialize spec-kit in the subdirectory: cd /work/my-project && specify init
  4. Create a new feature: specify new "My feature"

Expected Behavior

  • Specs should be created in /work/my-project/specs/
  • The .specify directory location should define the project root

Actual Behavior

  • Specs are created in /work/specs/ (parent directory)
  • git rev-parse --show-toplevel finds the parent's .git and uses that as root

Root Cause

In scripts/bash/common.sh (lines 5-13), get_repo_root() prioritizes git rev-parse --show-toplevel over .specify directory detection:

get_repo_root() {
    if git rev-parse --show-toplevel >/dev/null 2>&1; then
        git rev-parse --show-toplevel    # <-- ALWAYS wins if ANY parent has .git
    else
        # Fallback only used when git completely fails
        ...
    fi
}

The same issue exists in:

  • scripts/bash/create-new-feature.sh (lines 171-181)
  • scripts/powershell/common.ps1 (lines 4-16)
  • scripts/powershell/create-new-feature.ps1

Ironically, there's a correct find_repo_root() function in create-new-feature.sh (lines 77-88) that checks for BOTH .git and .specify, but it's only used as a fallback when git fails completely.

Proposed Fix

Invert the logic - .specify should be the primary marker for spec-kit root:

  1. First search upward from CWD for .specify directory
  2. If found, use that directory as the spec-kit root
  3. Only use git as fallback if no .specify found

This ensures spec-kit respects its own initialization boundary rather than inheriting a parent git repo.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions