Inspect staged and unstaged changes plus recent commit subjects.
Identify the dominant user-visible intent. Split into multiple commits when one diff mixes unrelated intents.
Choose a Conventional Commit type, optional scope, and ! only for real breaking changes.
Prefix the subject with the single most appropriate Gitmoji. Prefer one Gitmoji, not a chain.
Write an imperative subject focused on the change outcome, not a file-by-file summary.
Keep the full subject concise. Prefer 72 characters or fewer after the Gitmoji when practical.
Add a body only when it improves clarity. Use it to explain why, impact, rollout notes, or migration details.
Add footers only when relevant, such as BREAKING CHANGE:, issue refs, or trailers.

Favor wording that can be promoted into human changelog entries.
Optimize for notable outcomes: Added, Changed, Deprecated, Removed, Fixed, Security.
Do not dump raw commit logs into changelog-style prose.
Call out deprecations, removals, and breaking changes explicitly.

Default to feat for net-new behavior and fix for bug fixes.
Use docs, refactor, perf, test, build, ci, chore, style, or revert when they better match the primary intent.
Use ! and a BREAKING CHANGE: footer when compatibility changes need migration guidance.
Prefer stable, codebase-recognizable scopes such as package, service, feature, or subsystem names.

Output contract

Return one best commit message by default.
If the user asks for options, return 2-3 distinct subjects.
When asked to create the commit, produce the final message in ready-to-run form.
When uncertain between nearby Gitmoji choices, prefer the more general and widely understood option.

Advanced features

See REFERENCE.md for type-to-changelog guidance and Gitmoji selection.

See EXAMPLES.md for ready-made commit examples.