use case

Generate conventional commits that feed automated release and changelog workflows

Modern CI/CD pipelines rely on commit message conventions to determine version bumps, generate changelogs, and trigger releases. git-agent produces correctly formatted conventional commits that integrate seamlessly with semantic-release, release-please, and conventional-changelog — so your pipeline always has the right signals.

The challenge

CI/CD tools like semantic-release parse commit messages to decide whether to bump MAJOR, MINOR, or PATCH. If developers write vague or inconsistent commit messages, the pipeline either bumps the wrong version or skips a release entirely. Manual enforcement of commit standards across a team is unreliable and slows down developers.

The solution

git-agent generates conventional commits with accurate types, scopes, and optional BREAKING CHANGE footers — all the signals your CI/CD pipeline needs. When integrated into your workflow, every commit that reaches the pipeline is correctly formatted, ensuring reliable version bumps, changelogs, and release triggers every time.

Implementation steps

Configure your CI/CD pipeline (e.g., semantic-release, release-please) to read commits from your default branch as usual.
Have your team hand completed work to `git-agent --intent "..."` instead of running `git add` and `git commit`. The agent generates conventional messages and owns the Git workflow automatically.
Run `git-agent init` per project to set up scopes and a validation hook, ensuring consistent message quality across the team.
Trigger your pipeline on push. The pipeline reads the conventional messages and computes the correct version bump, generates changelog entries, and publishes releases automatically.

FAQ

Does git-agent integrate directly with semantic-release or release-please?

git-agent does not call these tools directly. It produces the conventional commit messages they consume. The commits it generates are fully compatible with any tool that parses the Conventional Commits specification.

How does git-agent handle BREAKING CHANGE detection for version bumps?

When the LLM detects an incompatible API change — such as removed parameters, renamed exports, or changed function signatures — it adds a BREAKING CHANGE footer and a ! before the colon, triggering a MAJOR version bump in your CI/CD pipeline.

Can I use git-agent in a CI environment (e.g., GitHub Actions)?

git-agent is designed for interactive handoff from a completed working tree. For CI environments, use it where the job has a writable checkout and pass the change intent explicitly; otherwise let developers hand off their local work before it reaches the pipeline.

Conventional Commits explained Semantic versioning explained Commit message format explained