You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature]: git extension: scope the after_implement auto-commit to the files the command changed #5025
The after_implement auto-commit of the git extension runs git add ., so it commits everything in the working tree, including work unrelated to the implementation.
Reproduction on 1.2.1, with auto_commit.after_implement.enabled: true: leave an unrelated file in the tree (echo "side work" > README.md), let the implementation create src/feature.txt, run the hook. The commit contains both files.
Proposed Solution
An opt-in way to limit the auto-commit to the files the command changed, the default staying git add ..
#2478 was closed because the extension cannot know which files belong to the commit. The agent that just ran the command does know. We run this as a local patch (the agent passes the paths to auto-commit.sh) and can propose a design and a PR if the direction suits you.
Alternatives Considered
.gitignore: does not apply, the unrelated file is meant to be committed, just not in this commit.
before_implement auto-commit: moves the unrelated work into another commit instead of leaving it alone, and does not help when another agent works in the same checkout.
Component
Scripts (Bash/PowerShell utilities)
AI Agent (if applicable)
Claude Code
AI Disclosure
Drafted with Claude Code (Claude Opus 5.5, human-supervised): the reproduction was run by the agent, and the text was reviewed and edited by the human contributor before posting.
Thanks for the detailed proposal. Yes, this can be delivered as your own preset.
Presets sit above extensions in the resolution stack and can override both the core speckit.implement command and the git extension's speckit.git.commit command. The preset could declare the git extension dependency and provide these command replacements:
The speckit.implement wrapper would preserve the standard implementation instructions while requiring the agent to write the paths it created, modified, renamed, or deleted to a temporary manifest, for example .specify/tmp/after-implement-paths.
The replacement speckit.git.commit command could then use that manifest only for the after_implement event:
Other hook events could continue invoking the existing git extension script, preserving its current behavior.
The key requirement is that the implementing agent must produce the path list. The commit hook cannot derive file ownership from git status, because unrelated working-tree changes are indistinguishable by then.
Given that this is an opt-in workflow policy and can be implemented without changing the hook contract or default auto-commit behavior, a separately maintained preset—potentially published as a community preset—is the appropriate solution, so I am closing this as not planned for the first-party git extension.
AI disclosure: Posted on behalf of @mnriem with GitHub Copilot using GPT-5.6 Sol in human-supervised agent mode; Copilot assessed preset feasibility and drafted this maintainer response.
Activity
mnriem commentedon Oct 19, 2026
Thanks for the detailed proposal. Yes, this can be delivered as your own preset.
Presets sit above extensions in the resolution stack and can override both the core
speckit.implementcommand and the git extension'sspeckit.git.commitcommand. The preset could declare the git extension dependency and provide these command replacements:The
speckit.implementwrapper would preserve the standard implementation instructions while requiring the agent to write the paths it created, modified, renamed, or deleted to a temporary manifest, for example.specify/tmp/after-implement-paths.The replacement
speckit.git.commitcommand could then use that manifest only for theafter_implementevent:git add --pathspec-from-file=.specify/tmp/after-implement-paths git commit -m "$message" rm -f .specify/tmp/after-implement-pathsOther hook events could continue invoking the existing git extension script, preserving its current behavior.
The key requirement is that the implementing agent must produce the path list. The commit hook cannot derive file ownership from
git status, because unrelated working-tree changes are indistinguishable by then.Given that this is an opt-in workflow policy and can be implemented without changing the hook contract or default auto-commit behavior, a separately maintained preset—potentially published as a community preset—is the appropriate solution, so I am closing this as not planned for the first-party git extension.
AI disclosure: Posted on behalf of @mnriem with GitHub Copilot using GPT-5.6 Sol in human-supervised agent mode; Copilot assessed preset feasibility and drafted this maintainer response.