Conventional Commit Generator
Paste a short description of what you changed and get a properly formatted Conventional Commits v1.0 message: correct type (feat, fix, chore, refactor, etc.), appropriate scope, concise imperative subject line, and a body when the change warrants it. Starter scenarios cover feature work, bug fixes, breaking API changes, and commitlint failures. Breaking changes are marked with ! or a BREAKING CHANGE footer. Includes examples for commitlint, semantic-release, release-please, and changesets. Powered by Amazon Nova Micro on AWS Bedrock.
Start with a common commit scenario
Pick the closest shape, then replace the details with your actual change before generating.
Conventional Commit guides
Pick the exact commit problem first, then use the generator with cleaner context.
Which Conventional Commit type should I use?
Pick the type based on the user-visible effect first, then the files changed. A UI bug fix in a refactored file is still fix.
The user can do something new after this change.
feat(billing): add invoice export
The change restores intended behavior that was broken.
fix(parser): preserve escaped pipe characters
The code structure changed but user-visible behavior did not.
refactor(auth): split token validation service
The same behavior is faster or uses fewer resources.
perf(search): cache parsed query filters
Only the CI pipeline, release workflow, or checks changed.
ci(actions): add deploy smoke test
Only docs, README files, examples, or comments changed.
docs(api): explain webhook retries
Release automation examples
fix(api): return 404 for missing invoices
semantic-release usually treats fix as a patch version bump.
feat(auth): add passkey login
feat usually creates a minor version bump because users get a new capability.
feat(api)!: remove v1 invoice endpoint
A bang or BREAKING CHANGE footer signals an incompatible change.
Conventional Commit types
- feat: new feature
- fix: bug fix
- docs: documentation only
- style: formatting, no code change
- refactor: restructure, no behavior change
- perf: performance improvement
- test: add or fix tests
- build: build system or deps
- ci: CI config changes
- chore: maintenance / tooling
- revert: revert a previous commit
Based on the Conventional Commits v1.0 specification. Breaking changes get a ! suffix or a BREAKING CHANGE: footer.
Common Workflows
Use these patterns when you need this tool for a real publishing, documentation, or developer workflow.
Turn a messy change summary into a Conventional Commit
Developers who know what changed but do not want to hand-pick feat, fix, chore, refactor, test, or docs.
- Describe the code change in plain English
- Include the area touched, such as auth, api, ui, docs, or ci
- Review the generated type, scope, subject, body, and breaking-change footer
A commit message that works with commitlint, semantic-release, release-please, and changesets.
Search intent: generate conventional commit message from change description
Package a breaking change for release automation
Teams using semantic versioning where breaking changes need to be explicit and machine-readable.
- Mention the removed behavior or incompatible migration
- Generate a Conventional Commit with a bang or BREAKING CHANGE footer
- Copy the result into git commit or your IDE commit field
A breaking-change commit message that downstream release tooling can detect.
Search intent: conventional commit breaking change generator
Standardize commits before opening a PR
Developers cleaning up local commits before pushing or opening a pull request.
- Paste one change at a time
- Generate concise commit subjects for each logical unit
- Use the related PR description and changelog tools after the commits are clean
A cleaner commit history that reviewers and release tooling can understand.
Search intent: semantic commit message generator for pull request
Fix a commitlint or semantic-release failure
Developers whose CI failed because a commit subject, type, scope, or breaking-change marker is not valid.
- Paste the failed commit message and what changed
- Regenerate a valid Conventional Commit with the right type and release signal
- Amend the commit or use it while squashing before merge
A commit message that passes commitlint and produces the expected release behavior.
Search intent: fix commitlint conventional commit message
Summarize an AI coding session into one clean commit
Claude Code, Codex, Copilot, Cursor, or agent-assisted changes where the diff spans files but should still be one logical commit.
- Paste the outcome of the coding session instead of every file changed
- Call out whether users see new behavior, fixed behavior, docs, tests, CI, or refactoring
- Generate one Conventional Commit, then use the PR description tool for the fuller change narrative
A machine-readable commit message that release tools can interpret even when the implementation came from an AI coding assistant.
Search intent: AI coding assistant conventional commit message generator
Example Input and Output
Turn a feature summary into a commit message
Added password reset flow. Users can request an email token, open the reset link, and set a new password. Changes are in AuthService and the login page.
feat(auth): add password reset flow Allow users to request an email reset token, open the reset link, and set a new password from the login flow.
The scope is auth because the description names AuthService and the login page. The type is feat because the user can do something new.
Mark a bug fix correctly
Fixed markdown table export. The last column was dropped when a row ended with an escaped pipe character.
fix(markdown): preserve escaped pipes in table export Keep escaped pipe characters inside table cells so the final column is not dropped during export.
This should be fix, not refactor, because it restores broken behavior that users could observe.
Handle a breaking API change
Removed the v1 invoices endpoint and replaced it with /v2/invoices. Clients must pass accountId instead of customerId.
feat(api)!: replace v1 invoices endpoint Remove the v1 invoices endpoint and add /v2/invoices with accountId-based requests. BREAKING CHANGE: clients must call /v2/invoices and pass accountId instead of customerId.
Breaking changes need either the ! marker or a BREAKING CHANGE footer. This output uses both because migration details matter.
Describe a CI-only change
Updated GitHub Actions to run the smoke tests after the Next.js build and before the deploy step.
ci(actions): run smoke tests before deploy Run the smoke test suite after the Next.js build and before the deployment step in GitHub Actions.
Use ci when the change only affects CI workflows, checks, deployment jobs, or automation config.
Avoid over-releasing docs-only work
Updated the README with setup instructions for local development and added examples for environment variables.
docs(readme): add local development setup instructions Document local setup steps and environment variable examples for contributors.
Use docs for documentation-only changes so release automation does not treat the change like a feature or bug fix.
Fix a commitlint failure
Commitlint failed for: updated auth stuff. The change fixes refresh token expiry in AuthService and adds a regression test.
fix(auth): refresh expired session tokens Refresh expired session tokens in AuthService and cover the expiry path with a regression test.
A valid subject uses a known type, an optional scope, and an imperative verb. The tool should not preserve vague subjects like 'updated stuff'.
Test your AI fundamentals next
If this tool is part of your AI or developer workflow, the free CloudYeti diagnostic shows which AWS AI concepts you already know and where you are weak.
Take the AI diagnosticHow to Use Conventional Commit Generator
- Open the Conventional Commit Generator
- Choose a starter scenario if your change is a feature, bug fix, breaking API change, or commitlint failure
- Describe the code change in plain English, including the affected area if there is one
- Mention whether the change is a feature, bug fix, refactor, test, CI, or breaking change if you know
- Generate the commit message
- Review the type, scope, subject, body, and any BREAKING CHANGE footer
- Copy the message into git commit, your IDE commit box, or your release automation flow
- Use the PR description or changelog tools when you need the next artifact from the same change summary
Frequently Asked Questions
- What is a Conventional Commit?
- A Conventional Commit is a commit message format like feat(auth): add password reset. The type describes the change, the optional scope names the affected area, and the subject says what changed in imperative form.
- Which commit type should I use?
- Use feat for a new user-facing capability, fix for a bug fix, docs for documentation-only changes, refactor for code restructuring without behavior changes, test for tests, ci for workflow changes, build for dependencies or build tooling, and chore for maintenance.
- How do I mark a breaking change?
- Use an exclamation mark after the type or scope, such as feat(api)!: remove v1 endpoint, and include a BREAKING CHANGE footer when the migration needs explanation.
- Does this work with semantic-release and commitlint?
- Yes. The generated message follows the Conventional Commits v1.0 shape used by commitlint, semantic-release, release-please, changesets, and similar release automation tools.
- Which Conventional Commit creates a release?
- In common release automation, fix usually creates a patch release, feat creates a minor release, and any commit with ! or a BREAKING CHANGE footer creates a major release. Other types such as docs, test, chore, ci, and refactor usually do not publish a release unless your tooling is configured differently.
- How do I fix a commitlint failure?
- Paste the failed subject, the commitlint error, and what changed. A valid Conventional Commit needs a known type, an optional lowercase scope, a concise imperative subject, and a BREAKING CHANGE footer only when the change is incompatible.
- What Conventional Commit type should I use for AI coding changes?
- Use the same rule as any other code change. A Claude Code, Codex, Copilot, or Cursor-assisted change is feat when users get a new capability, fix when behavior is restored, refactor when behavior is unchanged, test for tests, ci for pipeline changes, and docs for documentation-only work.
Related Tools
PR Description Generator
Describe your change, get a structured pull request description with summary, changes, test plan, and reviewer notes. GitHub-Flavored Markdown. Free, no login.
Git Branch Namer
Describe your task, get 3 concise git branch names following type/scope-short-summary convention. Free, no login.
Changelog Generator
Generate a Markdown changelog following Keep a Changelog format. Free online changelog builder.
Git Command Explainer
Paste any git command and get a plain-English breakdown of each flag, what it destroys, and a safer alternative. Free, no login.
About Conventional Commit Generator
Describe your change in plain English, get a Conventional Commits message with the right type, scope, subject, and release signal. Includes commitlint and semantic-release examples. Free, no login. This AI-backed tool sends your input to MarkdownMe's capped Amazon Bedrock endpoint to generate the result. No account is required. MarkdownMe provides free, fast, and reliable Markdown tools for developers, writers, and anyone who works with Markdown.