Create Conventional Commit Message

You are writing a git commit message following the Conventional Commits v1.0.0 specification.

1. Identify Changes

•Check git diff or recent commits for modified files
•Identify which features/modules were changed
•Note any new files, deleted files, or renamed files

2. Verify Current Implementation

CRITICAL: DO NOT trust existing documentation. Read the actual code.

For each changed file:

•Read the current implementation
•Understand actual behavior (not documented behavior)
•Note any discrepancies with existing docs

3. Conventional Commits Format

All commit messages must follow this structure:

code

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Types

Type	Use when...
`feat`	Adding new functionality (SemVer MINOR)
`fix`	Fixing a bug (SemVer PATCH)
`docs`	Documentation only changes
`style`	Formatting, semicolons, etc. (no code change)
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependency changes
`chore`	Maintenance tasks, tooling, config
`ci`	CI configuration and scripts

Scope

•Optional, in parentheses after type: feat(auth): add OAuth2 support
•Describes the section of the codebase affected

Breaking Changes

•Append an exclamation mark before the colon: feat!: remove deprecated login endpoint
•And/or add a footer: BREAKING CHANGE: login endpoint removed, use /auth instead
•Breaking changes correlate with SemVer MAJOR

Body

•Separated from description by a blank line
•Free-form, can be multiple paragraphs
•Explain what and why, not how

Footers

•Follow git trailer convention
•Use - instead of spaces in tokens (except BREAKING CHANGE which must be uppercase)

4. Output Format

Provide output the user can copy/paste into a UI git app and a CLI command.

For UI git apps:

•Title: <type>[scope]: <description>
•Body: the body and footer sections (if any)

CLI command:

bash

git commit -m "<type>[scope]: <description>" -m "<body>" -m "<footer>"

5. Style Rules

✅ Concise - Sacrifice grammar for brevity ✅ Practical - Examples over theory ✅ Accurate - Code verified, not assumed ✅ Current - Matches actual implementation

❌ No enterprise fluff ❌ No outdated information ❌ No assumptions without verification

6. Ask if Uncertain

If you're unsure about intent behind a change or user-facing impact, ask the user — don't guess. This is especially important for choosing between feat and fix, and for identifying breaking changes.