Problem Statement
The bundled git extension currently supports auto-commit hooks using fixed/static commit messages from git-config.yml.
This works for the default Spec Kit workflow, but it does not fit teams that use Conventional Commits for changelogs, release automation, semantic versioning, or CI policy checks.
For example, today the extension can produce messages like [Spec Kit] Add specification or [Spec Kit] Add implementation plan, but some projects need messages like feat: add OAuth specification or docs: update implementation plan.
There does not appear to be a built-in way to keep using the Git extension’s auto-commit hooks while asking the agent to generate Conventional Commit messages from the actual diff.
Proposed Solution
Add a new configuration option to the bundled git extension, for example:
commit_style: fixed
Supported values:
fixed - default; preserve the current behavior and use configured/static messages.
conventional - ask the agent to inspect the relevant changes and provide a Conventional Commit message.
In conventional mode:
auto_commit should still control whether commits happen for each hook/event.
- The configured
auto_commit.<event>.message values should not be used as the primary commit message source.
- The agent-facing
speckit.git.commit command should instruct the agent to inspect the diff and generate an appropriate Conventional Commit message.
- The shell/PowerShell scripts should receive the generated message explicitly, for example via an argument or environment variable such as
SPECKIT_COMMIT_MESSAGE.
- If no generated message is provided, the command should fail or skip with a clear warning instead of silently falling back to the fixed message format.
This would keep semantic commit-message generation in the agent layer while keeping the Git scripts simple and deterministic.
Alternatives Considered
Possible alternatives:
- Manually edit the generated commit messages after each auto-commit. This defeats much of the value of auto-commit hooks.
- Disable the Git extension’s auto-commit hooks and commit manually. This works, but loses the integrated Spec Kit lifecycle behavior.
- Add custom local scripts outside the bundled extension. This is flexible, but each project has to reinvent the same behavior.
- Try to generate Conventional Commit messages inside the shell/PowerShell scripts. This seems less desirable because the scripts should not be responsible for semantic diff analysis.
Component
Other
AI Agent (if applicable)
None
Use Cases
- Teams using Conventional Commits with automated changelog generation.
- Projects using semantic-release or similar release automation.
- Repositories with CI checks that enforce Conventional Commit format.
- Teams that want Spec Kit lifecycle auto-commits while preserving project commit conventions.
- Multi-agent workflows where commit message style should be configured once in
git-config.yml.
Acceptance Criteria
Additional Context
The current Git extension already centralizes commit hook behavior in:
extensions/git/config-template.yml
extensions/git/git-config.yml
extensions/git/commands/speckit.git.commit.md
extensions/git/scripts/bash/auto-commit.sh
extensions/git/scripts/powershell/auto-commit.ps1
This seems like a natural place to add a small configuration option without changing the broader Spec Kit workflow.
Problem Statement
The bundled
gitextension currently supports auto-commit hooks using fixed/static commit messages fromgit-config.yml.This works for the default Spec Kit workflow, but it does not fit teams that use Conventional Commits for changelogs, release automation, semantic versioning, or CI policy checks.
For example, today the extension can produce messages like
[Spec Kit] Add specificationor[Spec Kit] Add implementation plan, but some projects need messages likefeat: add OAuth specificationordocs: update implementation plan.There does not appear to be a built-in way to keep using the Git extension’s auto-commit hooks while asking the agent to generate Conventional Commit messages from the actual diff.
Proposed Solution
Add a new configuration option to the bundled
gitextension, for example:commit_style: fixedSupported values:
fixed- default; preserve the current behavior and use configured/static messages.conventional- ask the agent to inspect the relevant changes and provide a Conventional Commit message.In
conventionalmode:auto_commitshould still control whether commits happen for each hook/event.auto_commit.<event>.messagevalues should not be used as the primary commit message source.speckit.git.commitcommand should instruct the agent to inspect the diff and generate an appropriate Conventional Commit message.SPECKIT_COMMIT_MESSAGE.This would keep semantic commit-message generation in the agent layer while keeping the Git scripts simple and deterministic.
Alternatives Considered
Possible alternatives:
Component
Other
AI Agent (if applicable)
None
Use Cases
git-config.yml.Acceptance Criteria
extensions/git/config-template.ymlincludes a documentedcommit_styleoption.commit_stylecontinue to behave exactly as they do today.commit_style: fixedpreserves current fixed/static commit message behavior.commit_style: conventionalcausesspeckit.git.committo ask the agent to generate a Conventional Commit message from the diff.Additional Context
The current Git extension already centralizes commit hook behavior in:
extensions/git/config-template.ymlextensions/git/git-config.ymlextensions/git/commands/speckit.git.commit.mdextensions/git/scripts/bash/auto-commit.shextensions/git/scripts/powershell/auto-commit.ps1This seems like a natural place to add a small configuration option without changing the broader Spec Kit workflow.