Generate clean conventional commit messages from diffs and change descriptions.
You are a developer writing a git commit message. Given a description of changes or a diff summary, write a clear commit message.
Rules:
- Use conventional commit format: type(scope): description
- Valid types: feat, fix, refactor, docs, test, chore, perf, style, ci, build
- Subject line must be under 72 characters
- Use imperative mood ("add feature" not "added feature")
- Do not start with "This commit..."
- Include a body paragraph for complex changes, separated by a blank line
- The body should explain WHY, not WHAT (the diff shows what changed)
- Scope is optional but encouraged when changes are focused on one area
Added a dark mode toggle to the settings page. New component DarkModeSwitch with localStorage persistence. Updated the ThemeProvider to read the saved preference on mount. Added CSS variables for dark theme colors.
A conventional commit message with type 'feat', clear scope, imperative mood subject under 72 chars, and a body explaining the persistence and theme provider changes
Fixed a bug where the checkout total was calculated before applying discount codes. The subtotal function was called before the discount middleware ran, causing users to see the wrong price on the confirmation page. Moved the subtotal calculation after the discount pipeline.
A conventional commit message with type 'fix', describing the timing issue concisely in the subject, with a body explaining the root cause (ordering of subtotal vs discount)
Extracted the authentication logic from three different API route handlers (login, register, reset-password) into a shared auth middleware. No behavior changes. Reduced total auth-related code from 340 lines to 120 lines.
A conventional commit message with type 'refactor', mentioning the extraction/consolidation in the subject, body noting no behavior change and the scope of reduction
Updated React from 18.2.0 to 19.0.0. Had to migrate three components from useEffect cleanup to the new useEffectEvent API. Also updated react-dom and @types/react to matching versions.
A conventional commit message with type 'chore' or 'build', mentioning the React 19 upgrade in the subject, body noting the migration effort and companion package updates
Changed the /api/users endpoint response format from a flat array to a paginated object with { data, total, page, perPage } shape. All existing clients will need to update their parsing logic. Added pagination query params ?page=1&perPage=20.
A conventional commit message with a BREAKING CHANGE footer or ! after the type, clearly describing the response shape change, with body explaining the migration impact
Added a getting started guide to the README with installation steps, environment variable setup, and a quickstart example. Also added a troubleshooting section for the three most common setup errors.
A conventional commit message with type 'docs', concise subject about the README additions, no body needed since the change is straightforward
Added unit tests for the calculateShipping function covering: free shipping threshold, weight-based rates, international surcharge, express vs standard, and edge case of zero-weight items. 12 new test cases total.
A conventional commit message with type 'test', mentioning the function name and coverage scope in the subject, optionally noting the number of test cases
# Commit Message Optimization Strategy
## Goals
- Strict conventional commit format compliance
- Imperative mood, always ("add" not "added")
- Subject lines that communicate the change in under 72 characters
- Bodies that explain WHY, not WHAT
## Preferred Strategies
- **constrain** — Enforce character limits, ban past tense, ban "This commit..." openers
- **sharpen** — Add rules for choosing the correct commit type and when to include a body
- **add_example** — Show good/bad commit message pairs for each type (feat, fix, refactor, etc.)
## Avoid
- Never use past tense in commit messages ("added", "fixed", "updated", "removed")
- Never start with "This commit..."
- Never repeat the subject line content in the body
- Never use "expand" to add unnecessary verbosity — commit messages should be tight
- Avoid "remove" — the prompt is already minimal, removing rules would break format compliance
## Hints
- The commit type is the most common error — guide the model to distinguish feat vs fix vs refactor vs chore
- Scope should match the directory or module affected: feat(auth):, fix(cart):, refactor(api):
- Subject line trick: complete the sentence "If applied, this commit will ___"
- Body is only needed for complex changes — simple renames or doc fixes need no body
- BREAKING CHANGE footer is required when the public API changes, not optional
- "chore" vs "build": chore = tooling/config, build = build system/dependencies
- The WHY test: if the body just restates the diff in English, it adds no value — explain the motivation instead