* fix(scripts): prioritize .specify over git for repo root detection
When spec-kit is initialized in a subdirectory that doesn't have its
own .git, but a parent directory does, spec-kit was incorrectly using
the parent's git repository root. This caused specs to be created in
the wrong location.
The fix changes repo root detection to prioritize .specify directory
over git rev-parse, ensuring spec-kit respects its own initialization
boundary rather than inheriting a parent git repo.
Fixes#1932
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: address code review feedback
- Normalize paths in find_specify_root to prevent infinite loop with relative paths
- Use -PathType Container in PowerShell to only match .specify directories
- Improve has_git/Test-HasGit to check git command availability and validate work tree
- Handle git worktrees/submodules where .git can be a file
- Remove dead fallback code in create-new-feature scripts
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: check .specify before termination in find_specify_root
Fixes edge case where project root is at filesystem root (common in
containers). The loop now checks for .specify before checking the
termination condition.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: scope git operations to spec-kit root & remove unused helpers
- get_current_branch now uses has_git check and runs git with -C to
prevent using parent git repo branch names in .specify-only projects
- Same fix applied to PowerShell Get-CurrentBranch
- Removed unused find_repo_root() from create-new-feature.sh
- Removed unused Find-RepositoryRoot from create-new-feature.ps1
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: use cd -- to handle paths starting with dash
Prevents cd from interpreting directory names like -P or -L as options.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix: check git command exists before calling get_repo_root in has_git
Avoids unnecessary work when git isn't installed since get_repo_root
may internally call git rev-parse.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix(powershell): use LiteralPath and check git before Get-RepoRoot
- Use -LiteralPath in Find-SpecifyRoot to handle paths with wildcard
characters ([, ], *, ?)
- Check Get-Command git before calling Get-RepoRoot in Test-HasGit to
avoid unnecessary work when git isn't installed
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix(powershell): use LiteralPath for .git check in Test-HasGit
Prevents Test-Path from treating wildcard characters in paths as globs.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* fix(powershell): use LiteralPath in Get-RepoRoot fallback
Prevents Resolve-Path from treating wildcard characters as patterns.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
---------
Co-authored-by: iamaeroplane <michal.bachorik@gmail.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
The $Number (Int32) parameter was implicitly receiving positional
arguments intended for $FeatureDescription, causing a
ParameterBindingArgumentTransformationException when AI agents
called the script with positional strings.
Add [Parameter(Position = 0)] to $FeatureDescription so it binds
first, and mark $Number with [Parameter()] (no Position) so it
only binds by name (-Number N).
Fixes#1879
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The check_existing_branches (bash) and Get-NextBranchNumber (PowerShell)
functions no longer use the short_name parameter since they now find the
global maximum across ALL features. This commit:
1. Removes the unused parameter from function signatures
2. Updates all call sites to not pass the parameter
This prevents the scripts from failing when the function is called with
the wrong number of arguments.
The check_existing_branches (bash) and Get-NextBranchNumber (PowerShell)
functions were only looking for branches/specs matching the SAME short name
when determining the next feature number. This caused collisions where
multiple features could be assigned the same number if they had different
short names.
For example, if feature 023-ci-optimization existed, creating a new feature
with a different short name would incorrectly use 001 instead of 024.
This fix changes both functions to:
1. Use get_highest_from_branches() / Get-HighestNumberFromBranches to find
the highest number across ALL branches globally
2. Use get_highest_from_specs() / Get-HighestNumberFromSpecs to find the
highest number across ALL spec directories globally
3. Return the maximum of both + 1
The helper functions already existed but were not being used. This fix
properly utilizes them to ensure features are numbered sequentially
regardless of their short names.
Issue: Branch number collisions when creating features with different names
Impact: Prevents multiple features from sharing the same number prefix
Refactored both Bash and PowerShell create-new-feature scripts to modularize and deduplicate logic for determining the next feature number, including new helper functions for extracting the highest number from specs and branches. Improved branch name cleaning and generation. In update-agent-context scripts, removed redundant updates to AGENTS.md for Copilot, streamlining agent update logic.
- Use git ls-remote for more reliable remote branch detection
- Check remote branches, local branches, AND specs directories
- Match exact short-name pattern to avoid false positives
- Ensures no duplicate numbers across all sources
- Add --number parameter to create-new-feature scripts (bash & PowerShell)
- Add check_existing_branches() function to fetch and scan remote branches
- Update branch numbering logic to check remotes before creating new branches
- Update /speckit.specify command to document remote branch checking workflow
- Prevents duplicate branch numbers when branches exist on remotes but not locally
- Maintains backward compatibility with existing workflows
- Falls back to local directory scanning when Git is not available
