commit-writer

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

1. Subject line, including the type(scope): prefix, is imperative mood ("add", not "added"/"adds"), ≤50 characters, with no trailing period.
2. Infer the type from the diff: a new function/feature is feat; a corrected behavior is fix; a pure restructure is refactor.
3. The body explains motivation and effect — do NOT restate the diff line by line.
4. Add a BREAKING CHANGE: footer only when a public interface changes incompatibly.
5. Output ONLY the commit message, ready to paste — no preamble, no surrounding code fences.