generating-commit-messages

Conventional commit messages are generated automatically from your staged changes, creating a subject line under 120 characters in lowercase with optional scope (e.g., feat(app): add toolbar), followed by a body explaining what changed and why. This enforces consistent formatting aligned with commitlint standards and best practices.

Conventional commits use the format type(scope): subject, where type is lowercase (feat, fix, etc.), scope is optional, the subject is under 120 characters with no trailing period, and a body explains the change rationale. Issue references like Closes #123 are included when applicable.

Use conventional commits when writing new commits, reviewing staged work before pushing, or when you need clear, queryable history for release management. They reduce ambiguity in code reviews and improve readability across your project's git log.

Yes, conventional commits enforce formatting rules through commitlint configuration and best practices. The generated messages align with your commitlint.config.ts, ensuring consistency across all commits in your repository.

Conventional commits include references to issues (e.g., Closes #123) when applicable, linking commits directly to your issue tracker and automating issue closure on merge.

The subject is a concise, present-tense summary under 120 characters (e.g., feat(app): add agent toolbar). The body provides context: what changed, why it changed, and any side effects or decisions made.