Skip to content

[Feature]: Add configurable Conventional Commit support to the bundled Git extension #3390

Description

@grafvonb

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

  1. Teams using Conventional Commits with automated changelog generation.
  2. Projects using semantic-release or similar release automation.
  3. Repositories with CI checks that enforce Conventional Commit format.
  4. Teams that want Spec Kit lifecycle auto-commits while preserving project commit conventions.
  5. Multi-agent workflows where commit message style should be configured once in git-config.yml.

Acceptance Criteria

  • extensions/git/config-template.yml includes a documented commit_style option.
  • Existing projects without commit_style continue to behave exactly as they do today.
  • commit_style: fixed preserves current fixed/static commit message behavior.
  • commit_style: conventional causes speckit.git.commit to ask the agent to generate a Conventional Commit message from the diff.
  • Bash and PowerShell auto-commit scripts can accept an explicit generated commit message.
  • In conventional mode, missing generated commit messages produce a clear warning/failure instead of silently using fixed messages.
  • Tests cover default behavior, fixed mode, conventional mode, and missing-message behavior.
  • Documentation is updated for the Git extension configuration.

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions