Commit Message Writer

Generate Conventional Commit messages, PR titles, and summaries from git diffs, code snippets, or change descriptions for any project or language.

Description

Write Conventional Commit messages from a git diff, code snippet, or plain description. Also generates PR titles and 3-bullet PR summaries. Works with any language and any project — no setup, no config.

Use when

• "write a commit message"
• "what should I commit this as"
• "conventional commit for this diff"
• "write a PR title and description"
• Any git diff or code change needing a message

Supported conventions

• Conventional Commits 1.0 (default)
• Angular commit format
• GitHub squash-merge style
• Plain descriptive (no convention)

Request a specific one or it defaults to Conventional Commits.

Input

Paste one of:

• A git diff (git diff --staged)
• A description of what changed ("I added rate limiting to the API")
• Code before/after

Optionally specify:

• Convention (defaults to Conventional Commits)
• Scope (component, module, or area affected)
• Whether this is a breaking change

Output format

## Commit Message

[type]([scope]): [subject]

[body — explains WHY, not just WHAT. Omitted if obvious from subject]

[BREAKING CHANGE: description — only if applicable]
[Closes #123 — only if issue number is known]

---

## PR Title
[short, imperative, under 70 chars]

## PR Summary
- [What changed]
- [Why it changed / what problem it solves]
- [Any notable side effects, caveats, or follow-up needed]

Conventional Commits type guide

Type	When to use
feat	New feature (triggers minor version bump)
fix	Bug fix (triggers patch version bump)
docs	Documentation only
style	Formatting, whitespace — no logic change
refactor	Restructure without changing behavior
perf	Performance improvement
test	Adding or fixing tests
chore	Build system, CI, dependency updates
revert	Reverts a prior commit
ci	CI pipeline changes

Writing rules

• Subject: imperative mood ("add", "fix", "remove" — not "added", "fixed", "removes")
• Subject: no period at end
• Subject: under 72 characters
• Body: explain WHY the change was made, not just what the diff shows
• Breaking change: always include BREAKING CHANGE: footer with migration notes
• Scope: use the module, file, or feature name (e.g., auth, api, db, ui)
• If the diff touches multiple concerns: suggest splitting into multiple commits

Examples

Simple fix

fix(auth): reject expired JWT tokens before checking claims

Previously, token expiry was checked after claim validation,
which allowed attackers to replay expired tokens with valid claims.

New feature with breaking change

feat(api)!: require API key on all public endpoints

BREAKING CHANGE: All requests now require `X-API-Key` header.
Clients using anonymous access will receive 401. See migration guide.

Dependency update

chore(deps): bump openssl from 1.1.1 to 3.0.8

Addresses CVE-2023-0286 (X.400 address type confusion).
No API changes.

Self-improvement instructions

After each commit message written, note whether the input was a diff, description, or code snippet. After 20 uses, surface the most common missing context that leads to weaker messages.