At Commit

Commit Message Generator

Workflow

1. Run git diff --staged to inspect staged changes. If it is empty, tell the user to run git add first and stop.
2. Determine the description language using the Language Policy below.
3. Generate the message(s) and show them for confirmation; do not commit immediately. When more than one framing is reasonable, present them as a short numbered list (1), 2), …) so the user can pick by replying with just the number. A single clear message may be shown on its own. The user may also reply with an edit or their own wording.
4. Run git commit -m only after the user picks or explicitly confirms — a number from the list, "commit", or "ok" all count. Do not run git push unless the user explicitly asks.

Language Policy

Use this priority order for the human-readable description after type(scope)::

1. Use the language explicitly requested by the user in this turn.
2. Otherwise use the repository preference in .agent-tools/config.jsonc, if it defines at-commit.language.
3. Otherwise use the global preference in ~/.agent-tools/config.jsonc, if it defines at-commit.language.
4. Otherwise use the language of the user's actual invocation text when it contains a clear, independent natural-language request. Ignore injected skill instructions, quoted or pasted content, code blocks, diffs, and tool output.
5. Otherwise match the dominant language in recent repository commit subjects.
6. If no dominant language is clear, default to English.

Apply this order literally and stop at the first match. Check items 2 and 3 before item 4. A bare slash command or skill invocation has no language; continue to item 5. Inspect at most the latest 20 subjects.

Keep Conventional Commits syntax tokens untranslated: type, optional scope, !, and BREAKING CHANGE. Keep identifiers, file names, package names, commands, API names, and scopes in their original language.

Persistent Language Preference

Do not write config during ordinary commit generation. If the user explicitly asks to remember a commit-description language, offer to persist it. Ask repo vs global when scope is ambiguous.

For repo preference, create or update .agent-tools/config.jsonc; for global preference, use ~/.agent-tools/config.jsonc:

{
  "at-commit.language": "zh-CN"
}

Preserve unrelated keys and comments when practical. Do not require prior installer setup.

Rules

Read git diff --staged and generate a Conventional Commits title that explains WHAT changed and, when useful, WHY.

• Title: type(scope): description, <= 74 characters, no trailing period, no prefix, no quotes, no code block.
• type: choose exactly one:
  • feat for a feature, fix for a bug fix
  • refactor for behavior-preserving restructuring, perf for performance
  • docs for documentation-only changes, style for formatting-only changes
  • test for adding or fixing tests, build for build systems or dependencies, ci for CI config/scripts
  • chore for miscellaneous changes that do not touch src/test, revert for reverts
• scope: optional affected module name. Use this repository's convention. In monorepos, use the app/package directory name. Omit it for cross-cutting changes or when unsure.
• description: one concise verb-object phrase in the selected natural language. Avoid filler equivalent to "update files", "this commit", "misc changes", or "several changes". Preserve identifiers, function names, file names, package names, commands, and APIs as written.
• single line only: commit messages always contain only the title line. Do not write a body or footer. Compress necessary WHY into the title.
• breaking changes: mark with type(scope)!: description, still as one line. Do not use a BREAKING CHANGE footer.
• punctuation: use ASCII punctuation throughout the title, including in non-English descriptions. Non-ASCII characters are allowed only in words and identifiers. Normalize localized punctuation before showing or committing the title.