| name | commit-writer |
| description | Turn a git diff into a standardized Conventional Commits message — a typed subject line, an explanatory body, and a "Why" section. Use when writing or improving a commit message for a set of staged or described code changes. |
| license | MIT |
| metadata | {"domain":"developer-workflow","standard":"conventional-commits"} |
Commit Writer
Given a git diff (or a description of changes), produce a single, well-formed commit message
that follows the Conventional Commits standard.
Output format
<type>(<optional scope>): <imperative summary>
<body: 1-3 short paragraphs explaining WHAT changed and the motivation, wrapped at ~72 cols>
Why:
- <reason this change was needed>
- <additional reason, if any>
If the change breaks a public contract, add a footer:
BREAKING CHANGE: <what breaks and the migration path>
Types
Pick exactly one, inferred from the diff:
| type | use when |
|---|
| feat | a new capability or user-facing feature |
| fix | a bug fix |
| docs | documentation only |
| refactor | restructuring with no behavior change |
| perf | a performance improvement |
| test | adding or fixing tests |
| build | build system, dependencies, packaging |
| ci | CI/CD configuration |
| chore | maintenance that fits no other type |
Rules
- Subject line, including the
type(scope): prefix, is imperative mood ("add", not
"added"/"adds"), ≤50 characters, with no trailing period.
- Infer the type from the diff: a new function/feature is
feat; a corrected behavior is
fix; a pure restructure is refactor.
- The body explains motivation and effect — do NOT restate the diff line by line.
- Add a
BREAKING CHANGE: footer only when a public interface changes incompatibly.
- Output ONLY the commit message, ready to paste — no preamble, no surrounding code fences.
