conventional-commit

name	conventional-commit
description	Draft or review Conventional Commits messages with type, optional scope, imperative summary, body, footer, and breaking-change notes. Use when user asks for a commit message, commit title and body, changelog-safe wording, or commit-format review. Do not use for PR descriptions; use summarize-branch.

Conventional Commits

Write machine-readable commit messages.

When to Use

• Drafting commit messages.
• Reviewing commit message quality.
• Preparing release notes or changelogs.
• Creating consistent team conventions.

Goal

Use Conventional Commits format. Make intent clear. Support automated tooling.

Format

<type>[optional scope]: <description>

[optional body]

[optional footer]

Types

• feat: new feature.
• fix: bug fix.
• docs: documentation only.
• style: formatting or code style only.
• refactor: code change without feature or bug fix.
• perf: performance improvement.
• test: tests added or changed.
• build: build system or dependency change.
• ci: CI change.
• chore: maintenance.
• revert: revert previous commit.

Header Rules

• Use imperative present tense: add, not added or adds.
• Start description lowercase.
• Do not end with a period.
• Keep concise.
• Add scope only when useful: fix(auth): remove stale token.

Body and Footer Rules

• Use body when context matters.
• Explain what and why.
• Use bullets for multiple changes.
• Wrap lines around 72 characters.
• Use BREAKING CHANGE: ... for breaking changes.
• Reference issues when useful: Closes #123.

feat(ui): add dark mode toggle

fix(auth): remove blocking overlay on login button

- adjust overlay z-index so it sits behind the button
- keep pointer events available for the login CTA

feat(api): migrate to REST v2 endpoints

BREAKING CHANGE: All API endpoints are now prefixed with /api/v2.

Output

## Commit Message
[message]

## Notes
- Type: [type]
- Scope: [scope or none]
- Breaking change: [yes/no]